From ghc-devs at haskell.org Wed Jan 1 07:55:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Jan 2014 07:55:55 -0000 Subject: [GHC] #8645: Improper response from GHCI terminal after importing Gnuplot package Message-ID: <051.926a46b3cb70a08f679d592a060daaf2@haskell.org> #8645: Improper response from GHCI terminal after importing Gnuplot package ---------------------------------+------------------------------------- Reporter: pankajsejwal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: ghci, gnuplot | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ---------------------------------+------------------------------------- I recently tried one simple example on plotting using Haskell wrapper for Gnuplot on ubuntu using this example:[http://www.linuxquestions.org/questions/blog/hydramax-533365 /quick-and-dirty-plotting-with-haskell-gnuplot-35230/] . It works fine, but after I close the graph window and type anything in GHCI terminal, it doesn't show it being typed. On entering text and pressing return it executes it in a normal way. I tried with unloading all modules but to no avail. Has someone else faced it earlier ? GHC : 7.6.3 Linux : Ubuntu 12 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 1 11:18:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Jan 2014 11:18:35 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.bf0f5c74860df6ada37cec3deaecb1e4@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: klangner Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by klangner): Ok. Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 1 13:18:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Jan 2014 13:18:18 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.baeb1c0f21a72b74aea16908be2d34f4@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: klangner => nomeata Comment: Looks good; validating right now... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 1 13:45:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Jan 2014 13:45:54 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.0098c2e396694e36e05ff5f8a1ca5312@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"d0b74cac0b0ab5371d15b6f73c0e627b41c3a152/base"]: {{{ #!CommitTicketReference repository="base" revision="d0b74cac0b0ab5371d15b6f73c0e627b41c3a152" Improve error messages for partial functions in Data.Data This closes: #5412 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 1 13:46:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Jan 2014 13:46:29 -0000 Subject: [GHC] #5412: dataTypeConstrs gives unhelpful error message In-Reply-To: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> References: <051.725025e2f5a74cbcdbc139f819da79d1@haskell.org> Message-ID: <066.c10185a6164e0663e6efe722a250d288@haskell.org> #5412: dataTypeConstrs gives unhelpful error message -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Validated and pushed. Thanks for your first contribution to GHC, and hoping to receive more of them! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 1 21:54:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Jan 2014 21:54:13 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.ff876efdbd19be2af34c03d3652f2aa3@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:7 simonpj]: > Great. Now, what's happening in `symalg` and `kahan` (+4.7 and 6.7% resp)? Thunks are happening... (see below) > What is puzzling to me is that I don't think `smartJ#` does ''any'' allocation (apart from its result) so I don't see why allocation should ever increase. ...because I missed the fact that `(# smartJ# ... , smartJ# ... #)` creates a thunk (there was even a source code comment about that pitfall in `quotRemInteger#`) However, I replaced all `smartJ#`-in-`(#,#)` occurences (incl. `decodeDouble`) by `let !x = smartJ# ... in (# x, ... #)` constructs, and the results look better now: {{{ Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ... gamteb +0.1% -19.0% 0.03 0.03 +0.0% ... kahan +0.2% -1.2% 0.17 0.17 +0.0% ... mandel +0.1% -7.7% 0.05 0.05 +0.0% ... power +0.1% -40.8% -32.5% -32.5% +0.0% ... symalg +0.2% -0.5% 0.01 0.01 +0.0% ... -------------------------------------------------------------------------------- Min +0.0% -40.8% -32.5% -32.5% -5.1% Max +0.2% +0.1% +2.0% +2.0% +0.0% Geometric Mean +0.1% -1.0% -2.5% -2.5% -0.1% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 1 21:55:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Jan 2014 21:55:09 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.81fa204c09b3ca791af589fcfdc3cfde@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 14:30:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 14:30:00 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c Message-ID: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> #8646: Distinguish between update frames in rts/Printer.c ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When doing printf-debugging and using Printer.c, it would be nice to see exact kind of update frame. (See attached patch) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 14:37:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 14:37:35 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c In-Reply-To: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> References: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> Message-ID: <062.6597742b7508fb4dc8b8bef33c3eec4b@haskell.org> #8646: Distinguish between update frames in rts/Printer.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: feature request | Status: patch Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 14:38:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 14:38:52 -0000 Subject: [GHC] #8606: Fix whitespaces in rts/sm/Scav.c In-Reply-To: <047.6a57100d3db9294020694d3e91dba13b@haskell.org> References: <047.6a57100d3db9294020694d3e91dba13b@haskell.org> Message-ID: <062.a5f36097ee51938aa6e15f354e3278a0@haskell.org> #8606: Fix whitespaces in rts/sm/Scav.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: task | Status: closed Priority: lowest | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * status: patch => closed * resolution: => wontfix Comment: Nevermind, I shouldn't open whitespace-only patches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 15:13:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 15:13:51 -0000 Subject: [GHC] #8625: GHCi does not support some TH elements, while those elemenst are working in hs files In-Reply-To: <046.0f31ee1e49a02b8e04444700e0dded78@haskell.org> References: <046.0f31ee1e49a02b8e04444700e0dded78@haskell.org> Message-ID: <061.0229f3989ef72e1c2f6bf9e3e335b0e2@haskell.org> #8625: GHCi does not support some TH elements, while those elemenst are working in hs files -------------------------------------+------------------------------------ Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"053a9d15031b0b33adc77eaadc5536a43dc7de33/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="053a9d15031b0b33adc77eaadc5536a43dc7de33" Handle parens in predicates when converting to TH This fixes Trac #8625 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 15:15:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 15:15:14 -0000 Subject: [GHC] #8625: GHCi does not support some TH elements, while those elemenst are working in hs files In-Reply-To: <046.0f31ee1e49a02b8e04444700e0dded78@haskell.org> References: <046.0f31ee1e49a02b8e04444700e0dded78@haskell.org> Message-ID: <061.36f99b56637155a206b19bbf4416692e@haskell.org> #8625: GHCi does not support some TH elements, while those elemenst are working in hs files -------------------------------------+------------------------------------ Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"6425ccb4fc85c4e1d03dd21768697a989d3e8bc9/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="6425ccb4fc85c4e1d03dd21768697a989d3e8bc9" Test Trac #8625 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 15:36:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 15:36:30 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.c612825975edad9fb6966541ce097998@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Terrific, thanks. I'll commit. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 18:59:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 18:59:58 -0000 Subject: [GHC] #8475: Library docs: broken links to Foreign.ForeignPtr In-Reply-To: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> References: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> Message-ID: <062.24edf136d5c406f881c0324370b60ee6@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hellertime): * owner: => hellertime -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 19:12:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 19:12:20 -0000 Subject: [GHC] #8475: Library docs: broken links to Foreign.ForeignPtr In-Reply-To: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> References: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> Message-ID: <062.f34640094fd9caff3d2d616818a71fa8@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hellertime): * status: new => patch Comment: Haddock was being to not to document Foreign.ForeignPtr resulting in the incorrect links noted in this ticket. This patch removes the haddock pragma so that the documentation once again is generated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 21:10:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 21:10:37 -0000 Subject: [GHC] #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) In-Reply-To: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> References: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> Message-ID: <065.55da56637efa5d516e286989fb2f8847@haskell.org> #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) ---------------------------------------+----------------------------------- Reporter: SimonHengel | Owner: hellertime Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by hellertime): * owner: => hellertime -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 21:59:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 21:59:39 -0000 Subject: [GHC] #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) In-Reply-To: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> References: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> Message-ID: <065.be6fdcacf5c70a9bc8ee6e82a2fb33e0@haskell.org> #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) ---------------------------------------+----------------------------------- Reporter: SimonHengel | Owner: hellertime Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by hellertime): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 21:59:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 21:59:42 -0000 Subject: [GHC] #8636: Infix declaration on operators ending on backslash In-Reply-To: <049.f087d7cb3e1ecaa0bf93cea006d4da7c@haskell.org> References: <049.f087d7cb3e1ecaa0bf93cea006d4da7c@haskell.org> Message-ID: <064.27fef6ae4ba780a26164bd3716088c15@haskell.org> #8636: Infix declaration on operators ending on backslash ----------------------------------------------+---------------------------- Reporter: jcristovao | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects valid program | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by jcristovao): * status: new => closed * resolution: => invalid Comment: You are absolutly right, I had indeed enabled the CPP extension, and was oblivious of this unintended consequence. Sorry for the noise... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 22:01:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 22:01:22 -0000 Subject: [GHC] #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) In-Reply-To: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> References: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> Message-ID: <065.a6755f9c754c32f96396884562d546b2@haskell.org> #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) ---------------------------------------+----------------------------------- Reporter: SimonHengel | Owner: hellertime Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by hellertime): I swapped the arguments to (++) in runPp so that they match the documentation, and added a test to verify the correct operation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 2 22:18:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Jan 2014 22:18:10 -0000 Subject: [GHC] #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci In-Reply-To: <044.dea60e8093ada94b7dcc73a3c17d116a@haskell.org> References: <044.dea60e8093ada94b7dcc73a3c17d116a@haskell.org> Message-ID: <059.0b0607c74971890396bf94fbd8a5eae8@haskell.org> #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci -------------------------------+------------------------------------------- Reporter: dmwit | Owner: bennofs Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by bennofs): * cc: hvr (added) * difficulty: => Easy (less than 1 hour) * owner: => bennofs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 00:57:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 00:57:53 -0000 Subject: [GHC] #8475: Library docs: broken links to Foreign.ForeignPtr In-Reply-To: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> References: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> Message-ID: <062.843ad0ea30b8eff881d39c471b77f391@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * cc: davidterei@? (added) Comment: CC'ing David Terei, since he was the one originally responsible for adding the OPTIONS_HADDOCK hide to this module. David, was there any particular reason why you added that pragma in this commit? {{{ commit 555183b053d1ec9e27083c0f15f648a69c716bc2 Author: David Terei Tue May 17 05:57:46 2011 Committer: David Terei Sat Jun 18 16:06:34 2011 SafeHaskell: Added SafeHaskell to base }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 06:19:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 06:19:03 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.1d5627d42ec37ecd65b00b0686b29e2e@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by awson): Please, please, remember {{{-dynamic-too}}} does not work on Windows yet! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 06:43:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 06:43:50 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c In-Reply-To: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> References: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> Message-ID: <062.832674e45c99b9e8b61dcd3be4ddff6e@haskell.org> #8646: Distinguish between update frames in rts/Printer.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: feature request | Status: patch Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): It might be more robust if, in the failure check, it re-checked the closure type, and reported "unknown update frame" or "not an update frame" instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 07:45:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 07:45:16 -0000 Subject: [GHC] #5954: Performance regression 7.0 -> 7.2 (still in 7.4) In-Reply-To: <047.8be864281aa54fbc2cb186b2afb9a1a6@haskell.org> References: <047.8be864281aa54fbc2cb186b2afb9a1a6@haskell.org> Message-ID: <062.74ab4120b0efb1310295ccb2d41d9463@haskell.org> #5954: Performance regression 7.0 -> 7.2 (still in 7.4) --------------------------------------------+------------------------------ Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.6.2 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 carter): is this bug still going on in head? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 10:53:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 10:53:30 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c In-Reply-To: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> References: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> Message-ID: <062.e79479b2e1c7df82c2d17bfd163c1f85@haskell.org> #8646: Distinguish between update frames in rts/Printer.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: feature request | Status: patch Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Thanks for the quick reply, but I'm not sure I understood your suggestions: 1. By re-check, do you mean to check that `info->type == UPDATE_FRAME`? 2. By report, do you mean to use `barf()`? Won't it be enough to just do (2.)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 12:20:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 12:20:00 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c In-Reply-To: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> References: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> Message-ID: <062.c58dd4421a0b4320c349c60269aa1321@haskell.org> #8646: Distinguish between update frames in rts/Printer.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: feature request | Status: patch Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Your function has an invariant, "must be an UPDATE_FRAME". So logically, it should check if that invariant is violated. I think your check in (1) is the right one but I haven't double-checked. If an invariant is violated, barfing seems to be the right thing to do. Honestly, I would also barf when you expected an update frame but didn't get one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 12:55:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 12:55:33 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` Message-ID: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> #8647: Reduce allocations in `integer-gmp` ------------------------------+-------------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.6.3 (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8638 | ------------------------------+-------------------------------------------- I've added `printf(3)`s to `integer-gmp`s GMP allocation/reallocation functions, and noticed there to a significant amount of allocations going on. This is due to the fact that the CMM wrappers call `gmpz_init()` to initialize the result, and this already allocates a 1-limb `StgArray`. But the actual GMP operations perform a reallocate-call (which by contract also needs `memcpy` the untouched limb over to the newly allocated structure) based on the type of operation and the involved operands, causing the optimistically allocated 1-limb structure to become garbage right away w/o even being written to. I've been able to get rid of most such superfluous allocations by replacing {{{#!c ccall __gmpz_init(mp_result1 "ptr"); }}} by {{{#!c MP_INT__mp_alloc(mp_result1) = 0; MP_INT__mp_size(mp_result1) = 0; MP_INT__mp_d(mp_result1) = 0; // (1) }}} which is handled properly by all GMP operations we make use of currently. This elegantly lets the very first allocation be performed within the GMP operation (which has better knowledge with respect to how many limbs the result will require) I've got working proof-of-concept code, which reduces the allocations the big-num heavy `nofib` programs (I've omitted the benchmarks which had a 0% allocation change): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ... bernouilli -0.1% -5.2% 0.12 0.12 +0.0% kahan -0.1% -10.5% 0.17 0.17 +0.0% primetest -0.1% -12.8% 0.07 0.07 +0.0% rsa -0.1% -13.8% 0.02 0.02 +0.0% symalg -0.1% -2.3% 0.01 0.01 +0.0% ... -------------------------------------------------------------------------------- Min -0.1% -13.8% -3.1% -3.1% -6.5% Max -0.0% +0.4% +4.0% +4.0% +1.5% Geometric Mean -0.1% -0.5% +0.5% +0.4% -0.1% }}} `(1)` This should actually point to a proper static closure I didn't need this for the proof-of-concept ---- Another place which helps avoiding temporarily allocating 1-limb `StgArrays` which live only for the duration of GMP FFI calls are those caused by the `toBig`-casts, which I'm also experimenting by making use of GMP's big-int/small-int add/sub/mul primitives (the deltas shown above are actually measured on top of this optimization), here's what to expect from such an optimization by itself (i.e. w/o the realloc-optimization from above): {{{ bernouilli +0.1% -4.2% 0.12 0.12 +0.0% kahan +0.1% -12.6% 0.17 0.17 +0.0% power +0.1% -2.7% +2.2% +2.2% +0.0% rsa +0.1% -4.1% 0.02 0.02 +0.0% scs +0.1% -2.6% -1.6% -1.6% +0.0% }}} Thus, the `kahan` benchmark benefits from this optimization by -12.6%, and on top of that another -10.5% by also avoiding the GMP-reallocations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 12:57:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 12:57:45 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.300b156f3470f41a4cd9319b56a637ed@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8647 --------------------------------------------+------------------------------ Changes (by hvr): * related: => #8647 Comment: I've investigated some more how to optimize `integer-gmp`, see also #8647 The scary part is, that the `Integer` is involved in seemingly unrelated operations, such as operating on `Double` or `show`ing `Double` values, causing several avoidable allocations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 12:59:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 12:59:27 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.42fcd52a2f55d19edd3175aaaaae28f7@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Changes (by hvr): * keywords: => integer-gmp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 13:11:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 13:11:54 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.7cb886fb23fbc9a7555c86cdb78fc0d7@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by simonpj): That looks like a very worthwhile improvement. Please do make sure that you document the new code carefully. By definition, it wasn't obvious to whoever first wrote it! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 13:27:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 13:27:21 -0000 Subject: [GHC] #8475: Library docs: broken links to Foreign.ForeignPtr In-Reply-To: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> References: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> Message-ID: <062.a1223b1108e6076693ce31a82386630c@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: patch => infoneeded Comment: I'll change the status back to 'info needed', pending David's reply. Chris: do time out if David doesn't reply in a week or so. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 15:13:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 15:13:31 -0000 Subject: [GHC] #8639: GHC API `runStmt` overrides qualified import of `it` variable In-Reply-To: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> References: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> Message-ID: <064.f5af7556f12ee7d36e54eea2d3148cd3@haskell.org> #8639: GHC API `runStmt` overrides qualified import of `it` variable -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Turns out that you need also {{{ runStmt "hFlush stdout" RunToCompletion }}} to make the output appear when redirecting. Weird. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:14:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:14:29 -0000 Subject: [GHC] #8640: :show imports ignores -XNoImplicitPrelude In-Reply-To: <047.522405561fb51568dff539b89e1aa78b@haskell.org> References: <047.522405561fb51568dff539b89e1aa78b@haskell.org> Message-ID: <062.af18afc59b346b6786e1f5b5dbad8e4f@haskell.org> #8640: :show imports ignores -XNoImplicitPrelude -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"c93d664baa552e43c915e995663aa624bcfcd6ff/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c93d664baa552e43c915e995663aa624bcfcd6ff" In ':show imports' take account of -XNoImplicitPrelude Fixes Trac #8640 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:14:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:14:29 -0000 Subject: [GHC] #8628: dynCompileExpr breaks repeated runDecls of the same name In-Reply-To: <049.09ea66098fe70379109ad292dc66392d@haskell.org> References: <049.09ea66098fe70379109ad292dc66392d@haskell.org> Message-ID: <064.a5f7f1df75f1e74cf6bcb76eba2c5be1@haskell.org> #8628: dynCompileExpr breaks repeated runDecls of the same name -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"5dffb4ac14b53362ebe9a67c5c6a01f9c9c25229/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5dffb4ac14b53362ebe9a67c5c6a01f9c9c25229" Refactor the way shadowing in handled in GHCi If you say ghci> import Foo( T ) ghci> data T = MkT ghci> data T = XXX then the second 'data T' should shadow the first. But the qualified Foo.T should still be available. We really weren't handling this correctly at all, resulting in Trac #8639 and #8628 among others This patch: * Add RdrName.extendGlobalRdrEnv, which does shadowing properly * Change HscTypes.icExtendGblRdrEnv (was badly-named icPlusGblRdrEnv) to use the new function * Change RnNames.extendGobalRdrEnvRn to use the new function * Move gresFrom Avails into RdrName * Better pprGlobalRdrEnv function in RdrName }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:14:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:14:29 -0000 Subject: [GHC] #8639: GHC API `runStmt` overrides qualified import of `it` variable In-Reply-To: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> References: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> Message-ID: <064.de0f68649e7630a5452771bbd0ff9746@haskell.org> #8639: GHC API `runStmt` overrides qualified import of `it` variable -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"5dffb4ac14b53362ebe9a67c5c6a01f9c9c25229/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5dffb4ac14b53362ebe9a67c5c6a01f9c9c25229" Refactor the way shadowing in handled in GHCi If you say ghci> import Foo( T ) ghci> data T = MkT ghci> data T = XXX then the second 'data T' should shadow the first. But the qualified Foo.T should still be available. We really weren't handling this correctly at all, resulting in Trac #8639 and #8628 among others This patch: * Add RdrName.extendGlobalRdrEnv, which does shadowing properly * Change HscTypes.icExtendGblRdrEnv (was badly-named icPlusGblRdrEnv) to use the new function * Change RnNames.extendGobalRdrEnvRn to use the new function * Move gresFrom Avails into RdrName * Better pprGlobalRdrEnv function in RdrName }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:14:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:14:30 -0000 Subject: [GHC] #8644: 'Untouchable' error with constraint variable in rank-2 type In-Reply-To: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> References: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> Message-ID: <062.3319ab13147438cb50218064da8c7327@haskell.org> #8644: 'Untouchable' error with constraint variable in rank-2 type ----------------------------------------------+---------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9e10d1883d7ea5ea422cda79b426f51d2b59b14d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9e10d1883d7ea5ea422cda79b426f51d2b59b14d" Improve the equality-floating story (again), to fix Trac #8644 We float equalities out of implications whose 'givens' include equalities. But it's a bit tricky knowing whether some givens do or do not include equalities, as #8644 shows. There the given has type 'c' (which might have equalities), but we discover that 'c ~ ()', which definitely doesn't. In short, we must look at the givens *after* normalisation, not before. Moreover, something similar happens in approximateWC, where we need to ask whether an implication has given equalities. This patch does the job: * Add a Boolean field inert_no_eqs to InertCans, which records whether we've added a non-constant equality * Add a field ic_no_eqs to Implication, which records whether the ic_given binders include any equalities * Get rid of Inst.hasEqualities altogether On the way I did some un-forced refactoring * Introduce the auxiliary function TcCanonical.flattenNestedFamApp * Kill off FamHeadMap and PredMap in favour of the new FunEqMap and DictMap respectively }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:16:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:16:06 -0000 Subject: [GHC] #8639: GHC API `runStmt` overrides qualified import of `it` variable In-Reply-To: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> References: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> Message-ID: <064.26838fad2fe7c72337cd2155f6bafeb7@haskell.org> #8639: GHC API `runStmt` overrides qualified import of `it` variable -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"0a0ca8097d52838bf6faa883dfab4f84a7e89527/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="0a0ca8097d52838bf6faa883dfab4f84a7e89527" Test Trac #8639 (just the GHCi version) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:16:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:16:07 -0000 Subject: [GHC] #8639: GHC API `runStmt` overrides qualified import of `it` variable In-Reply-To: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> References: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> Message-ID: <064.f623d2e90427dd2ed564111e3f0c7b71@haskell.org> #8639: GHC API `runStmt` overrides qualified import of `it` variable -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"b56bee2c2340f0ce8f6759e989093c18d7a7bd40/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="b56bee2c2340f0ce8f6759e989093c18d7a7bd40" Test Trac #8639 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:16:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:16:07 -0000 Subject: [GHC] #8644: 'Untouchable' error with constraint variable in rank-2 type In-Reply-To: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> References: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> Message-ID: <062.1aee83129fe3f17f3fd0c3662c7ce797@haskell.org> #8644: 'Untouchable' error with constraint variable in rank-2 type ----------------------------------------------+---------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2818ec6887a713211dfca69cc80241a1ef2e5d33/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="2818ec6887a713211dfca69cc80241a1ef2e5d33" Test Trac #8644 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:16:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:16:08 -0000 Subject: [GHC] #8644: 'Untouchable' error with constraint variable in rank-2 type In-Reply-To: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> References: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> Message-ID: <062.ccb78a636f57f803f99f422b99f09373@haskell.org> #8644: 'Untouchable' error with constraint variable in rank-2 type ----------------------------------------------+---------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"cf68a8e798fea44bea2804439732e534e096b0d1/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="cf68a8e798fea44bea2804439732e534e096b0d1" Update T7594 as a result of fixing #8644 The fix to #8644 makes the original T7594 pass (rightly). I've added a variant that shouuld and does fail }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:17:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:17:54 -0000 Subject: [GHC] #8644: 'Untouchable' error with constraint variable in rank-2 type In-Reply-To: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> References: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> Message-ID: <062.7c21e2dd720377d5790dbbf76fec366d@haskell.org> #8644: 'Untouchable' error with constraint variable in rank-2 type -------------------------------------------------+------------------------- Reporter: sbarclay | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler (Type checker) | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple typecheck/should_compile/T8644 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T8644 * resolution: => fixed Comment: Great catch, thank you! This showed (in a nice simple example) that the handling of equality floating was inadequate. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:22:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:22:09 -0000 Subject: [GHC] #8640: :show imports ignores -XNoImplicitPrelude In-Reply-To: <047.522405561fb51568dff539b89e1aa78b@haskell.org> References: <047.522405561fb51568dff539b89e1aa78b@haskell.org> Message-ID: <062.4da42e4b47ed75bbc20c83bc082bf97e@haskell.org> #8640: :show imports ignores -XNoImplicitPrelude -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"1c446635e37428d73bac7789458d291650475913/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="1c446635e37428d73bac7789458d291650475913" Test Trac #8640 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:23:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:23:02 -0000 Subject: [GHC] #8640: :show imports ignores -XNoImplicitPrelude In-Reply-To: <047.522405561fb51568dff539b89e1aa78b@haskell.org> References: <047.522405561fb51568dff539b89e1aa78b@haskell.org> Message-ID: <062.83cd2f1cebb37bee584017c0b603768b@haskell.org> #8640: :show imports ignores -XNoImplicitPrelude ---------------------------------------+----------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8640 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghci/scripts/T8640 * resolution: => fixed Comment: Thanks, great example. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:25:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:25:29 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.2b8756efbfa9b719c35c668a230d64aa@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: fixed | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8647 --------------------------------------------+------------------------------ Changes (by simonpj): * status: patch => closed * resolution: => fixed Comment: Thanks. I committed two patches below. I'll close this one since you have opened a new ticket for #8647. Simon {{{ commit 301269aef0fb331bf272de4f6592eb71471a3b16 Author: Herbert Valerio Riedel Date: Mon Dec 30 16:05:20 2013 +0100 Try harder to demote results from `J#` to `S#` (re #8638) Signed-off-by: Herbert Valerio Riedel >--------------------------------------------------------------- 301269aef0fb331bf272de4f6592eb71471a3b16 GHC/Integer/Type.lhs | 92 ++++++++++++++++++++++++++++++++------------------ 1 file changed, 59 insertions(+), 33 deletions(-) }}} and {{{ commit 3c93d7f61821345f29b9ee8a99346fa464d708a4 Author: Simon Peyton Jones Date: Fri Jan 3 16:13:19 2014 +0000 Refactor and comment the smartJ# changes (re Trac #8638) >--------------------------------------------------------------- 3c93d7f61821345f29b9ee8a99346fa464d708a4 GHC/Integer/Type.lhs | 50 +++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 41 insertions(+), 9 deletions(-) diff --git a/GHC/Integer/Type.lhs b/GHC/Integer/Type.lhs index c206462..77d529a 100644 --- a/GHC/Integer/Type.lhs +++ b/GHC/Integer/Type.lhs @@ -152,21 +152,52 @@ toBig i@(J# _ _) = i -- | Demote 'J#' to 'S#' if possible. See also 'smartJ#'. toSmall :: Integer -> Integer -toSmall i@(S# _) = i -toSmall (J# 0# _) = S# 0# -toSmall (J# 1# mb#) | isTrue# (v ># 0#) = S# v +toSmall i@(S# _) = i +toSmall (J# s# mb#) = smartJ# s# mb# + + +-- | Smart 'J#' constructor which tries to construct 'S#' if possible +smartJ# :: Int# -> ByteArray# -> Integer smartJ# 0# _ = S# 0# smartJ# +1# mb# | isTrue# (v ># 0#) = S# v where v = indexIntArray# mb# 0# -toSmall (J# -1# mb#) | isTrue# (v <# 0#) = S# v +smartJ# (-1#) mb# | isTrue# (v <# 0#) = S# v where v = negateInt# (indexIntArray# mb# 0#) -toSmall i = i - --- | Smart 'J#' constructor which tries to construct 'S#' if possible -smartJ# :: Int# -> ByteArray# -> Integer -smartJ# s# mb# = toSmall (J# s# mb#) +smartJ# s# mb# = J# s# mb# \end{code} +Note [Use S# if possible] +~~~~~~~~~~~~~~~~~~~~~~~~~ +It's a big win to use S#, rather than J#, whenever possible. Not only +does it take less space, but (probably more important) subsequent +operations are more efficient. See Trac #8638. + +'smartJ#' is the smart constructor for J# that performs the necessary +tests. When returning a nested result, we always use smartJ# strictly, +thus + let !r = smartJ# a b in (# r, somthing_else #) to avoid creating +a thunk that is subsequently evaluated to a J#. +smartJ# itself does a pretty small amount of work, so it's not worth +thunking it. + +We call 'smartJ#' in places like quotRemInteger where a big input might +produce a small output. + +Just using smartJ# in this way has good results: + + Program Size Allocs Runtime Elapsed TotalMem +-------------------------------------------------------------------------------- + gamteb +0.1% -19.0% 0.03 0.03 +0.0% + kahan +0.2% -1.2% 0.17 0.17 +0.0% + mandel +0.1% -7.7% 0.05 0.05 +0.0% + power +0.1% -40.8% -32.5% -32.5% +0.0% + symalg +0.2% -0.5% 0.01 0.01 +0.0% +-------------------------------------------------------------------------------- + Min +0.0% -40.8% -32.5% -32.5% -5.1% + Max +0.2% +0.1% +2.0% +2.0% +0.0% + Geometric Mean +0.1% -1.0% -2.5% -2.5% -0.1% %********************************************************* %* * @@ -200,6 +231,7 @@ quotRemInteger (J# s1 d1) (J# s2 d2) (# s3, d3, s4, d4 #) -> let !q = smartJ# s3 d3 !r = smartJ# s4 d4 in (# q, r #) + -- See Note [Use S# if possible] {-# NOINLINE divModInteger #-} divModInteger :: Integer -> Integer -> (# Integer, Integer #) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:25:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:25:47 -0000 Subject: [GHC] #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci In-Reply-To: <044.dea60e8093ada94b7dcc73a3c17d116a@haskell.org> References: <044.dea60e8093ada94b7dcc73a3c17d116a@haskell.org> Message-ID: <059.9a8ec57eb095d7aa88ce035e0314a642@haskell.org> #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci -------------------------------+------------------------------------------- Reporter: dmwit | Owner: bennofs Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by bennofs): The bug is trivally fixed by putting the code for resetting the promt in a `finally` clause. The attached patch does just that. I don't know how I could add a test case for this bug. Is there a way to send Ctrl-C to ghci with the current testing infrastructure? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:27:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:27:38 -0000 Subject: [GHC] #8639: GHC API `runStmt` overrides qualified import of `it` variable In-Reply-To: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> References: <049.be8dc837cf02d09e814c29b69ace92a5@haskell.org> Message-ID: <064.6e0c0ff980df0d118e2d42eace714d01@haskell.org> #8639: GHC API `runStmt` overrides qualified import of `it` variable -------------------------------------------------+------------------------- Reporter: agibiansky | Owner: Type: bug | Status: Priority: normal | closed Component: GHC API | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: ghc-api/T8639_api, | Unknown/Multiple ghci/scripts/T8639 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghc-api/T8639_api, ghci/scripts/T8639 * resolution: => fixed Comment: Thanks for identifying this so well. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:29:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:29:00 -0000 Subject: [GHC] #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci In-Reply-To: <044.dea60e8093ada94b7dcc73a3c17d116a@haskell.org> References: <044.dea60e8093ada94b7dcc73a3c17d116a@haskell.org> Message-ID: <059.77e6c9a4723d0831492c08c03e0cb452@haskell.org> #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci -------------------------------+------------------------------------------- Reporter: dmwit | Owner: bennofs Type: bug | Status: patch Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by simonpj): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:34:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:34:06 -0000 Subject: [GHC] #8628: dynCompileExpr breaks repeated runDecls of the same name In-Reply-To: <049.09ea66098fe70379109ad292dc66392d@haskell.org> References: <049.09ea66098fe70379109ad292dc66392d@haskell.org> Message-ID: <064.b38ffc91d22cfe334176573d681a6c1f@haskell.org> #8628: dynCompileExpr breaks repeated runDecls of the same name -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"e5a95b0ae2318ecb2deda26e1421cf4b5c8327ab/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="e5a95b0ae2318ecb2deda26e1421cf4b5c8327ab" Test Trac #8628 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:34:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:34:33 -0000 Subject: [GHC] #8628: dynCompileExpr breaks repeated runDecls of the same name In-Reply-To: <049.09ea66098fe70379109ad292dc66392d@haskell.org> References: <049.09ea66098fe70379109ad292dc66392d@haskell.org> Message-ID: <064.b004b3f37368d162438cc207efc03983@haskell.org> #8628: dynCompileExpr breaks repeated runDecls of the same name -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T8628 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * testcase: => ghc-api/T8628 * resolution: => fixed Comment: Good example. Fixed! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:37:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:37:04 -0000 Subject: [GHC] #8625: GHCi does not support some TH elements, while those elemenst are working in hs files In-Reply-To: <046.0f31ee1e49a02b8e04444700e0dded78@haskell.org> References: <046.0f31ee1e49a02b8e04444700e0dded78@haskell.org> Message-ID: <061.aca2beb931d2b60cdf55b09a93691b9d@haskell.org> #8625: GHCi does not support some TH elements, while those elemenst are working in hs files -------------------------------------+------------------------------------ Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8625 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * testcase: => th/T8625 * resolution: => fixed Comment: Thank you. This one was easy, happily. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:50:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:50:23 -0000 Subject: [GHC] #8579: Loading a module in GHCi affects shadowing In-Reply-To: <047.a3d8af90e3aba7e66fe2065e6ddde916@haskell.org> References: <047.a3d8af90e3aba7e66fe2065e6ddde916@haskell.org> Message-ID: <062.8322d4e264acd58609b62a8fddbe4b74@haskell.org> #8579: Loading a module in GHCi affects shadowing -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"d00942324c0835d3840c72eb9c9803b2ff36b28a/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="d00942324c0835d3840c72eb9c9803b2ff36b28a" Test Trac #8579 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 16:51:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 16:51:44 -0000 Subject: [GHC] #8579: Loading a module in GHCi affects shadowing In-Reply-To: <047.a3d8af90e3aba7e66fe2065e6ddde916@haskell.org> References: <047.a3d8af90e3aba7e66fe2065e6ddde916@haskell.org> Message-ID: <062.e588ab281d33e5db53934d198fb15c80@haskell.org> #8579: Loading a module in GHCi affects shadowing ---------------------------------------+----------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8579 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghci/scripts/T8579 * resolution: => fixed Comment: Thanks. Fixed as part of the fix to #8639 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 17:03:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 17:03:27 -0000 Subject: [GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented In-Reply-To: <047.cfb9dd0cccf053eb65d46aac8dec8ad0@haskell.org> References: <047.cfb9dd0cccf053eb65d46aac8dec8ad0@haskell.org> Message-ID: <062.9e58e72164ff3bd508ab9c9f164a75b4@haskell.org> #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented -------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 17:12:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 17:12:10 -0000 Subject: [GHC] #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) In-Reply-To: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> References: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> Message-ID: <065.d76383fbd8521030d19f9e0c74a878b3@haskell.org> #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) ---------------------------------------+----------------------------------- Reporter: SimonHengel | Owner: hellertime Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by hellertime): I just re-formatted these patches so that my author information was reflecting the correct e-mail address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 17:14:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 17:14:06 -0000 Subject: [GHC] #5188: Runtime error when allocating lots of memory In-Reply-To: <046.23412d715d1f4494b90774a7c22b4d8d@haskell.org> References: <046.23412d715d1f4494b90774a7c22b4d8d@haskell.org> Message-ID: <061.483781ba9a4ebab6174cd9d4b77281fb@haskell.org> #5188: Runtime error when allocating lots of memory ---------------------------------+------------------------------ Reporter: knyblad | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------ Changes (by thoughtpolice): * cc: hvr (added) * status: patch => infoneeded Comment: Reid, any word here - would you like you tweak this patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 17:14:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 17:14:56 -0000 Subject: [GHC] #8475: Library docs: broken links to Foreign.ForeignPtr In-Reply-To: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> References: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> Message-ID: <062.83f17ed2f3f82be06ef9d1154d3c7028@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hellertime): Reformatted the patch to reflect my correct e-mail address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 17:22:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 17:22:25 -0000 Subject: [GHC] #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 In-Reply-To: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> References: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> Message-ID: <058.dad20110b01a9e6f49fdade65d912e94@haskell.org> #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 --------------------------------------+--------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.5 Resolution: | Keywords: Mountain Lion Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------------- Changes (by George): * status: infoneeded => new Comment: build of GHC head fails on Mavericks with gcc 4.8: ... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libgmp.a(mp_clz_tab.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libgmp.a(obprintf.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libgmp.a(obvprintf.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libgmp.a(obprntffuns.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libgmp.a(repl-vsnprintf.o) has no symbols libtool: link: ranlib .libs/libgmp.a /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libgmp.a(mp_clz_tab.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libgmp.a(obprintf.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libgmp.a(obvprintf.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libgmp.a(obprntffuns.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libgmp.a(repl-vsnprintf.o) has no symbols libtool: link: rm -fr .libs/libgmp.lax libtool: link: ( cd ".libs" && rm -f "libgmp.la" && cp -p "../libgmp.la" "libgmp.la" ) cp libraries/integer-gmp/gmp/gmpbuild/gmp.h libraries/integer-gmp/gmp/ cp libraries/integer-gmp/gmp/gmpbuild/.libs/libgmp.a libraries/integer- gmp/gmp/ inplace/bin/mkdirhier libraries/integer-gmp/gmp/objs cd libraries/integer-gmp/gmp/objs && /usr/bin/ar x ../libgmp.a ranlib libraries/integer-gmp/gmp/libgmp.a /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libraries/integer-gmp/gmp/libgmp.a(mp_clz_tab.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obprintf.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obvprintf.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obprntffuns.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libraries/integer-gmp/gmp/libgmp.a(repl-vsnprintf.o) has no symbols make: *** [all] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 17:24:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 17:24:01 -0000 Subject: [GHC] #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 In-Reply-To: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> References: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> Message-ID: <058.69f8c67c05faf70eb38154fd7ff8ce5e@haskell.org> #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 --------------------------------------+--------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.5 Resolution: | Keywords: Mountain Lion Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------------- Changes (by George): * cc: george.colpitts@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 17:29:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 17:29:50 -0000 Subject: [GHC] #8622: Importing modules in .ghci file doesn't work In-Reply-To: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> References: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> Message-ID: <060.7f32d5b4ca99cb41fcf11fd8f004eee6@haskell.org> #8622: Importing modules in .ghci file doesn't work ---------------------------------+---------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by simonpj): * cc: simonmar (added) Comment: Actually this is by design. You can only use `import` and `:module` for a module that either * is already loaded as part of the current program (`:show modules` tells you which ones are, I think), or * is a module of a visible package If you use `:load Macros` rather than `import Macros`, all is well. However, the [http://www.haskell.org/ghc/docs/latest/html/users_guide /interactive-evaluation.html user documentation] is not good on this point. Notably, it says (2.4.5.1) that "You cannot add a module to the scope if it is not loaded". But that's not true: you can also add (or `import`) any package module. Copying Simon M to check my statements here. If correct, I'll update the documentation. Simion -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 21:24:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 21:24:57 -0000 Subject: [GHC] #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci In-Reply-To: <044.dea60e8093ada94b7dcc73a3c17d116a@haskell.org> References: <044.dea60e8093ada94b7dcc73a3c17d116a@haskell.org> Message-ID: <059.aaa5107058598cf02822836d9767229d@haskell.org> #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci -------------------------------+------------------------------------------- Reporter: dmwit | Owner: bennofs Type: bug | Status: patch Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"4d70840db82065bf19767a5f7231a9b1a3f56e38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4d70840db82065bf19767a5f7231a9b1a3f56e38" Fix #5209: Reset GHCi prompt in multiline mode GHCi didn't reset the multiline prompt when an exception (in particular, the UserInterrupt exception) occured. This commit uses `finally` to reset the prompt in all cases. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 21:26:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 21:26:32 -0000 Subject: [GHC] #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci In-Reply-To: <044.dea60e8093ada94b7dcc73a3c17d116a@haskell.org> References: <044.dea60e8093ada94b7dcc73a3c17d116a@haskell.org> Message-ID: <059.018ae6559514ebff69ca37d8d453cf0b@haskell.org> #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci -------------------------------+------------------------------------------- Reporter: dmwit | Owner: bennofs Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: As far as I know, there's no easy to way to test Ctrl-C with current infrastructure, so I left it without a test. Thanks for the patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 21:45:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 21:45:23 -0000 Subject: [GHC] #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 In-Reply-To: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> References: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> Message-ID: <058.19a58b88827a548284db6249fe776a65@haskell.org> #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 --------------------------------------+--------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.5 Resolution: | Keywords: Mountain Lion Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------------- Comment (by carter): did you try making sure the gcc in your path points to a real gcc too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 3 21:52:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Jan 2014 21:52:37 -0000 Subject: [GHC] #8643: Silent name shadowing In-Reply-To: <044.8dd660a5555a309c811cd8326c7ebc8b@haskell.org> References: <044.8dd660a5555a309c811cd8326c7ebc8b@haskell.org> Message-ID: <059.209efb32460abd304e0ead3b2aa7949e@haskell.org> #8643: Silent name shadowing -------------------------------------+------------------------------------ Reporter: mirpa | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5288 -------------------------------------+------------------------------------ Comment (by simonpj): Thanks. Now I see. The problem is that * name-shadowing is a warning, not an error * if there are errors, GHC reports them and suppresses warnings In your example, your program had a type error, which was correctly reported; but the type error was caused by accidental name capture. But only the type error is reported; the warning is suppressed. It would be easy to report warnings as well as errors, rather than suppressing the warnings. That would help you, but will mix up warnings (which are no necessarily errors) with errors (which are). I'm open to suggestions here. Does anyone else have an opinion? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 10:02:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 10:02:28 -0000 Subject: [GHC] #8475: Library docs: broken links to Foreign.ForeignPtr In-Reply-To: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> References: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> Message-ID: <062.560893d34fef95228e093911313df696@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Well, there are two `Foreign.ForeignPtr` modules, one in `base` and one in `haskell2010`. I don't think we have a good story for what Haddock does in that case - which one gets listed in the contents? It should be safe to generate documentation for both, so that at least the hyperlinks would work correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 12:26:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 12:26:06 -0000 Subject: [GHC] #5361: regSpill: out of spill slots! In-Reply-To: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> References: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> Message-ID: <064.9ef1c424a688db9b240e62853e0eb926@haskell.org> #5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: regSpill panic Operating System: Linux | impossible Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: http://hackage.haskell.org/package/SHA| Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by kazu-yamamoto): * status: new => closed * resolution: => fixed Comment: SimonM said in http://www.haskell.org/pipermail/ghc- devs/2014-January/003611.html {{{ So, avoiding -fregs-graph should work around this with 7.8. }}} I verified that this is true. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 13:29:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 13:29:01 -0000 Subject: [GHC] #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 In-Reply-To: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> References: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> Message-ID: <058.ecbd9dfc558faa64ceca9c0523cc6d2f@haskell.org> #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 --------------------------------------+--------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.5 Resolution: | Keywords: Mountain Lion Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------------- Comment (by George): yes I did: $ gcc --version gcc-4.8 (GCC) 4.8.2 I'm basically following the instructions here: http://d.hatena.ne.jp/kazu- yamamoto/20131028/1382921924 When I use integer-simple instead it fails with "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist- install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP- DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.0 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O -fasm -no-user-package-db -rtsopts -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist- install/build -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno libraries/vector/dist- install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o Loading package ghc-prim ... linking ... done. Loading package integer-simple ... linking ... done. Loading package base ... : can't load .so/.DLL for: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/libiconv.dylib (dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/libiconv.dylib, 9): no suitable image found. Did find: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/libiconv.dylib: mach-o, but wrong filetype) make[1]: *** [libraries/vector/dist- install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 1 make: *** [all] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 14:04:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 14:04:06 -0000 Subject: [GHC] #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 In-Reply-To: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> References: <043.9c0c6ae0a9ecc6b011a4e64a0d3b06e3@haskell.org> Message-ID: <058.06a8861b7ab2c9a6c4add8990f3f19b7@haskell.org> #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 --------------------------------------+--------------------------------- Reporter: chak | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.5 Resolution: | Keywords: Mountain Lion Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------------- Changes (by George): * status: new => infoneeded Comment: issue with integer-gmp on Mavericks with Xcode 5 is ticket 8497, https://ghc.haskell.org/trac/ghc/ticket/8497, so this ticket is specifically for what the subject says: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 which brings us back to my earlier question above: is this a problem with the 64 bit versions of ghc 7.4.2 on 10.8? with either the 32 bit or 64 bit version of ghc 7.6.3 on 10.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 14:33:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 14:33:53 -0000 Subject: [GHC] #8475: Library docs: broken links to Foreign.ForeignPtr In-Reply-To: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> References: <047.8bd193d030c4711a041cae1146e4743d@haskell.org> Message-ID: <062.24817ff9aee0123c0dab80e19dc23889@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dterei): No no good reason I can remember. Fairly sure it was a copy-paste mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 14:46:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 14:46:09 -0000 Subject: [GHC] #5361: regSpill: out of spill slots! In-Reply-To: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> References: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> Message-ID: <064.88c5afb316c950727ca8629ca1b9f77e@haskell.org> #5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: regSpill panic Operating System: Linux | impossible Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: http://hackage.haskell.org/package/SHA| Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by monoidal): This is a workaround, but does it mean the ticket is fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 15:23:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 15:23:08 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.5fca1e8d7f28b88a89da5d6d8f5fd727@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by George): * cc: george.colpitts@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 15:27:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 15:27:08 -0000 Subject: [GHC] #8620: build of head on Mac 10.9 with xcode 5 fails with In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.26133f91051a2dcde76aad9dd9b99681@haskell.org> #8620: build of head on Mac 10.9 with xcode 5 fails with ----------------------------------------+---------------------------------- Reporter: George | 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: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by George): * failure: None/Unknown => Building GHC failed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 15:39:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 15:39:40 -0000 Subject: [GHC] #8620: build of head on Mac 10.9 with xcode 5 fails with In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.ac9f1b54118f11a3483ab9debd5d03d1@haskell.org> #8620: build of head on Mac 10.9 with xcode 5 fails with ----------------------------------------+---------------------------------- Reporter: George | 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: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by George): can't modify original ticket, adding missing WikiFormatting > make -j3 > fails with > > Configuring ghc-bin-7.7.20131217... > Warning: 'data-dir: ..' is a relative path outside of the source tree. This > will not work when generating a tarball with 'sdist'. > ghc.mk:100: {{{***}}} Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestarteditself3timesisthereamakefilebug for details. Stop. > make: {{{***}}} [all] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 16:08:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 16:08:05 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.db8681fff365ee98b324dbff44e56207@haskell.org> #8618: can't load .so/.DLL ---------------------------------------+----------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by nushio): I hit the same issue while installing {{{singletons}}} package using GHC 7.7.20131217 on {{{ Linux nusid 3.8-2-amd64 #1 SMP Debian 3.8.13-1 x86_64 GNU/Linux }}} The tail of the installation message was: {{{ Loading package mtl-2.1.2 ... : can't load .so/.DLL for: libHSmtl-2.1.2.so (libHSmtl-2.1.2.so: cannot open shared object file: No such file or directory) Failed to install singletons-0.9.3 cabal: Error: some packages failed to install: singletons-0.9.3 failed during the building phase. The exception was: ExitFailure 1 }}} The temporal solution to this was (as hinted by Feuerbach) to set {{{shared: True}}} in my {{{~/.cabal/config}}} file, and then to {{{cabal install mtl --force-reinstall --reinstall }}} . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 16:14:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 16:14:15 -0000 Subject: [GHC] #8648: Initialization of C statics broken in threaded runtime Message-ID: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> #8648: Initialization of C statics broken in threaded runtime ------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider a tiny package `static-value`, consisting of one Haskell file {{{ foreign import ccall unsafe "returnStaticValue" c_returnStaticValue :: IO CInt printStaticValue :: IO () printStaticValue = print =<< c_returnStaticValue }}} and one corresponding C file {{{ static int theStaticValue = 0; int returnStaticValue() { // Modify the static so the C compiler doesn't optimize it away return theStaticValue++; } }}} (test case is attached). If we call `printStaticValue` using the GHC API: {{{ runGhc (Just libdir) $ do flags0 <- getSessionDynFlags void $ setSessionDynFlags flags0 { hscTarget = HscInterpreted , ghcLink = LinkInMemory , ghcMode = CompManager } setContext $ [ IIDecl $ simpleImportDecl $ mkModuleName "StaticValue" ] _ <- runStmt "StaticValue.printStaticValue" RunToCompletion }}} then we see "0", as expected. However, if we compile this code using the threaded runtime, and we wrap the above code in a call to either `forkIO` or `forkOS`, then we see a different value printed (-907777, whatever that value is). Some notes: * I have been unable to reproduce this bug without using GHC as API; in particular, calling `printStaticValue` directly, wrapped in `forkIO` or `forkOS` or not, always works as expected. * If I change the initialization value of `staticValue` from 0 to anything else (say, 1234), we always get the right answer, never the uninitialized value. Presumably this is because non-zero values require some explicit code to be run (and it does get run), while a zero value gets initialized differently (and apparently, that's where the bug is). * I have reproduced this bug in both ghc 7.4 and 7.7.20131227. This ticket is the result of tracking down a problem with calling `createProcess` from within the GHC API, which would cause the parent process to stall. As it turns out, `runProcess.c` (from the `process` library) declares a `static long max_fd = 0`, and in `runInteractiveProcess` checks for this value to be 0, and if it is, does a syscall to figure out what the maximum FD is. But since this static does not get initialized properly (the bug reported in this ticket), it gets left at its (random? but always the same) value (281474975802879), so that the child process proceeds to close rather too many file descriptors (if close_fds was set to True) and the parent stalls. Indeed, changing the initialization to `static long max_fd = -1` (and adjusting the later check for zero accordingly) fixes this (so this is a viable workaround in `process` if we cannot track down the bug in GHC). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 16:28:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 16:28:42 -0000 Subject: [GHC] #8648: Initialization of C statics broken in threaded runtime In-Reply-To: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> References: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> Message-ID: <059.af74274ab548cce0c1057f55439019ee@haskell.org> #8648: Initialization of C statics broken in threaded runtime -------------------------------------+------------------------------------ Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): I should have mentioned, I can only reproduce this on Linux; on OSX I always get the right answer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 16:41:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 16:41:30 -0000 Subject: [GHC] #8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table` In-Reply-To: <044.5f5ec774064a8f6ab1662b91fc1d1daa@haskell.org> References: <044.5f5ec774064a8f6ab1662b91fc1d1daa@haskell.org> Message-ID: <059.346d4c429020c594f008f479480af2bd@haskell.org> #8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table` ---------------------------------------+---------------------------------- Reporter: jloos | 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-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by blitzcode): * cc: tim@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 17:42:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 17:42:58 -0000 Subject: [GHC] #8649: Disambiguate Repeated Identifiers for data types in error messages Message-ID: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> #8649: Disambiguate Repeated Identifiers for data types in error messages ------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If, in an interactive context, you redefine a type, but then try to use functions for the previous definition, it will (as expected) give you an error message. The following code would trigger this in an interactive context: {{{ data X = Y Int f (Y i) = i data X = Y Int | Z String f (Y 3) }}} However the error message is not very good: {{{ Couldn't match expected type `:Interactive.X' with actual type `:Interactive.X' }}} This is very uninformative to the user if they do not understand what's going on. The following GHC API code can replicate this: {{{ runDeclsWithLocation "Interactive.hs" 1 "data X = Y Int" runDeclsWithLocation "Asdf.hs" 2 "f (Y i) = i" runDeclsWithLocation "Bloop.hs" 3 "data X = Y Int | Z String" runStmtWithLocation "Test.hs" 4 "f (Y 3)" RunToCompletion }}} Note that varying the location given to `runStmt` and `runDecls` (the string as well as the line number) seems to have no effect upon anything. I started out with just "" but varied it to check - no effect on anything as far as I can tell. How can I make this error message more informative? I would ideally like something like {{{ Couldn't match expected type `:Interactive1.X' with actual type `:Interactive5.X' }}} or really anything that caused these types to be visibly different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 21:03:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 21:03:53 -0000 Subject: [GHC] #8620: build of head on Mac 10.9 with xcode 5 fails with In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.0519c3b22edb40d0c48d6ac363cf2c5c@haskell.org> #8620: build of head on Mac 10.9 with xcode 5 fails with ----------------------------------------+---------------------------------- Reporter: George | 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: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Old description: > make -j3 > fails with > > Configuring ghc-bin-7.7.20131217... > Warning: 'data-dir: ..' is a relative path outside of the source tree. > This > will not work when generating a tarball with 'sdist'. > ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile > bug? See > http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestarteditself3timesisthereamakefilebug > for details. Stop. > make: *** [all] Error 2 New description: {{{ make -j3 }}} fails with {{{ Configuring ghc-bin-7.7.20131217... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestarteditself3timesisthereamakefilebug for details. Stop. make: *** [all] Error 2 }}} -- Comment (by hvr): fixed wiki formatting in description -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 21:13:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 21:13:46 -0000 Subject: [GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) In-Reply-To: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> References: <042.e2b4c372649ba443c83acd6104d8dbd7@haskell.org> Message-ID: <057.04f9c34a44feee30cc38d0988372a99d@haskell.org> #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) --------------------------------------------+------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Resolution: fixed | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8647 --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:13 simonpj]: > Thanks. I committed two patches below. For convenience, here are Trac links for the two commits: * [301269aef0fb331bf272de4f6592eb71471a3b16/integer-gmp] * [3c93d7f61821345f29b9ee8a99346fa464d708a4/integer-gmp] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 21:54:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 21:54:03 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.71e7d5187fda0005afcbc61989d99414@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"baeeef7af6e37441d1fa28f4197a8cb878a9ef0b/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="baeeef7af6e37441d1fa28f4197a8cb878a9ef0b" Add new `mpz_mul_si`-based primop (re #8647) This primop helps reducing allocation by being able to pass one `S#` argument directly to the GMP multiplication primitive without needing to promote (and thus allocate a `ByteArray#` as well) the `J#` first. This benefits a few nofib benchmarks wrt to allocations (having most impact on `kahan` resulting in about 10% less allocations) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 21:54:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 21:54:04 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.ea2b268aae21920d2322d804a26526a3@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"8bf9541912c30ffb740d6ab67edcadcfbe4fc80b/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="8bf9541912c30ffb740d6ab67edcadcfbe4fc80b" Add new `mpz_{sub,add}_ui`-based primop (re #8647) This adds `{plus,minus}IntegerInt#` which help to reduce temporary allocations in `plusInteger` and `minusInteger`. This and the previous commit introducing `timesIntegerInt#` (i.e. baeeef7af6e) result in reduced allocations for the following nofib benchmarks on Linux/amd64: Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------ bernouilli +0.0% -4.2% 0.12 0.12 +0.0% kahan +0.1% -12.6% 0.17 0.17 +0.0% pidigits +0.0% -0.5% -4.7% -4.5% +0.0% power +0.0% -2.7% +3.1% +3.1% +9.1% primetest +0.0% -4.2% 0.07 0.07 +0.0% rsa +0.0% -4.1% 0.02 0.02 +0.0% scs +0.0% -2.6% -0.8% -0.7% +0.0% ------------------------------------------------------------------ Min +0.0% -12.6% -4.7% -4.5% -5.0% Max +0.1% +0.2% +3.1% +3.1% +9.1% Geometric Mean +0.1% -0.3% -0.0% +0.0% +0.1% ------------------------------------------------------------------ Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 4 22:19:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Jan 2014 22:19:24 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.b45495e9c59b45617e16414d902ca163@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by hvr): The two commits above implement the 2nd of the two proposed optimizations in the ticket description, the avoid-reallocations-optimization is a bit more difficult to get implemented properly (but I'm still working on it). Btw, this optimization helps also in cases, when several small-ints are added/multiplied to an accumulator as in e.g.: {{{#!hs sum (toInteger (maxBound :: Int) : [1..10000]) -- or product [1..100] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 5 22:18:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Jan 2014 22:18:31 -0000 Subject: [GHC] #8650: Unexpected behaviour of import ccall "header.h function" Message-ID: <042.6c752e15c4b7ff5eb43bc6ab27a23ec9@haskell.org> #8650: Unexpected behaviour of import ccall "header.h function" ------------------------------------+-------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- When I write {{{ foreign import ccall "myheader.h myfunction" function :: IO ... }}} Is GHC supposed to check the existence of the header file, or do anything with it? Because I can still write {{{"myheaderBLA.h myfunction"}}} and it doesn't care about the first word (no error, ever, not even in linking, executable builds all fine). ---- Relatedly, I can write {{{ foreign import ccall "some.rubbish" f :: IO ... }}} and as long as {{{"some.rubbish"}}} contains a dot, nothin in the system will ever complain. carter suggested that maybe names with a dot inside are ignored by a linker. This leads me to the question: In my example above, is {{{myheaderBLA.h}}} actually understood as some kind of file and ignored by e.g. GHC, or is it a garbled symbol name? In that case, why does http://www.haskell.org/onlinereport/haskell2010/haskellch8.html suggest {{{ccall "string.h strlen"}}}? In the other case, why would it suggest this if the {{{"string.h"}}} part is ignored? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 5 23:35:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Jan 2014 23:35:02 -0000 Subject: [GHC] #8650: Unexpected behaviour of import ccall "header.h function" In-Reply-To: <042.6c752e15c4b7ff5eb43bc6ab27a23ec9@haskell.org> References: <042.6c752e15c4b7ff5eb43bc6ab27a23ec9@haskell.org> Message-ID: <057.a4bd419fb90dec16c543d95193b2fe07@haskell.org> #8650: Unexpected behaviour of import ccall "header.h function" --------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by carter): so does ghc currently not check if the header file is visible among the enumerated include dirs when compiling the ffi binding? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 09:41:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 09:41:06 -0000 Subject: [GHC] #8651: 'Untouchable' error when using type function in class constraint in rank-2 type Message-ID: <047.64aa8af319a4eeeeafe09afd9844e657@haskell.org> #8651: 'Untouchable' error when using type function in class constraint in rank-2 type -------------------------------------------+------------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8644 #7594 | Test Case: | Blocking: -------------------------------------------+------------------------------- I noticed there are some cases that no longer compile after the recent fix for #8644, such as the following: {{{#!haskell {-# LANGUAGE RankNTypes, FlexibleContexts, TypeFamilies #-} import Data.Monoid type family Id a type instance Id a = a --type instance Id [a] = [Id a] foo :: (Monoid (Id String) => r) -> r foo x = x main :: IO () main = print $ foo "Hello" }}} Attempting to compile this on HEAD produces the same error in 'main' as reported in the earlier ticket: {{{ Couldn't match expected type ?s0? with actual type ?[Char]? ?s0? is untouchable }}} However, it compiles fine if the commented-out type family instance is used instead. It also compiles fine if the type family is replaced with an ordinary type synonym: {{{#!haskell type Id a = a }}} I guess that the problem is caused by equalities of the form t ~ [Char] introduced by the type family instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 10:15:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 10:15:25 -0000 Subject: [GHC] #3458: Allocation where none should happen In-Reply-To: <044.0be4f1c62ed65da810608cbf23db2085@haskell.org> References: <044.0be4f1c62ed65da810608cbf23db2085@haskell.org> Message-ID: <059.6cccfc77e8648ad70fbb4ce6431eae00@haskell.org> #3458: Allocation where none should happen ---------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by nomeata): Just for the record: The code {{{ #!haskell f x = let g y = if y then x else g y in case g x of True -> False False -> True }}} in comment:5 would also be improved by the common context transformation proposed here: http://www.haskell.org/pipermail/ghc- devs/2013-December/003481.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 10:29:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 10:29:33 -0000 Subject: [GHC] #5075: CPR optimisation for sum types if only one constructor is used In-Reply-To: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> References: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> Message-ID: <068.7849a30139e0d66b4fd888fdec0f416d@haskell.org> #5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Just to be clear: This ticket is left open because of comment:9, right? Also, in case someone looks here: The branch cpr-sum-types is considered dead; Its last commit ([9b0d70e/ghc]) is from October 2011, while CPR for sum types has hit master in January 2013 ([d3b8991/ghc]). (Maybe we should rename dead branches to dead/...?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 10:38:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 10:38:36 -0000 Subject: [GHC] #8652: Cross-compiling broken for ARM/Linux target Message-ID: <046.33a5a63859df99c4c61a0ea3e5b20d78@haskell.org> #8652: Cross-compiling broken for ARM/Linux target ----------------------------+---------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------- I've attempted to cross compile GHC HEAD on Ubuntu 13.10 with ubuntu's hard-float tool-chain and LLVM. I've configured GHC with: {{{ $ ./configure --target=arm-linux-gnueabihf }}} and compiling by make works till it fails with: {{{ 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/arm-linux-gnueabihf-nm" /usr/bin/arm-linux-gnueabihf-nm: includes/dist- derivedconstants/header/tmp.o: File format not recognized deriveConstants: readProcess: /usr/bin/arm-linux-gnueabihf-nm "includes /dist-derivedconstants/header/tmp.o" (exit 1): failed make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 }}} As a workaround for this issue, it's possible to use --with-gcc= and this way deriveConstants gets the right cross GCC. Looks like a bug somewhere in make machinery or configure itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 11:00:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 11:00:17 -0000 Subject: [GHC] #5075: CPR optimisation for sum types if only one constructor is used In-Reply-To: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> References: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> Message-ID: <068.6ed2c5c3711279020d5fddd8a48bead1@haskell.org> #5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Yes, I think it's just open because of comment 9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 11:20:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 11:20:19 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c In-Reply-To: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> References: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> Message-ID: <062.2547c360d8821acf5b3cef6ccab0a9f5@haskell.org> #8646: Distinguish between update frames in rts/Printer.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: feature request | Status: patch Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): I added a slightly changed patch. Now it barfs rather than returning a descriptive string-value. I think doing something as in (1) is redundant, since I exhaustively check against all types of update_frames in the `if`-statements. If it goes to the last else-branch, it's not an update frame. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 12:34:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 12:34:11 -0000 Subject: [GHC] #8652: Cross-compiling broken for ARM/Linux target In-Reply-To: <046.33a5a63859df99c4c61a0ea3e5b20d78@haskell.org> References: <046.33a5a63859df99c4c61a0ea3e5b20d78@haskell.org> Message-ID: <061.1e40f08d3df7c6a841b615765145097a@haskell.org> #8652: Cross-compiling broken for ARM/Linux target ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by kgardas): After further investigation, this looks like an issue in configure. When it is run without --with-gcc, it even generates incorrect settings file: {{{ $ cat settings [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", ""), ("ld command", "/usr/bin/arm-linux-gnueabihf-ld"), ("ld flags", ""), ("ld supports compact unwind", "NO"), ("ld supports build-id", "NO"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/bin/ar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/bin/perl"), ("target os", "OSLinux"), ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = SOFTFP}"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("Unregisterised", "NO"), ("LLVM llc command", "/usr/bin/llc"), ("LLVM opt command", "/usr/bin/opt") ] }}} When --with-gcc is used, then both C compiler command and also target's arch armABI field are correctly set. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 12:51:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 12:51:54 -0000 Subject: [GHC] #8653: panic the impossible happened Message-ID: <044.e0b9c1adcff7503aa4e4d858430a66aa@haskell.org> #8653: panic the impossible happened ------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- on the commandline: Warning: -package-conf is deprecated: Use -package-db instead GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package old-time-1.1.0.1 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package Win32-2.3.0.0 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package convertible-1.0.11.1 ... linking ... done. Loading package utf8-string-0.3.7 ... linking ... done. Loading package HDBC-2.3.1.2 ... linking ... done. Loading package filepath-1.3.0.1 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package haskelldb-2.2.2 ... linking ... done. Loading package haskelldb-hdbc-2.2.2 ... linking ... done. Loading package parsec-3.1.3 ... linking ... done. Loading package HDBC-postgresql-2.3.2.2 ... ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): loadArchive "C:/PROGRA~1/POSTGR~1/9.3/lib\\libpq.a": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc.exe: Unknown PEi386 section name `.idata$4' (while processing: C:/PROGRA~1/POSTGR~1/9.3/lib\libpq.a) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 12:53:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 12:53:30 -0000 Subject: [GHC] #8653: panic the impossible happened In-Reply-To: <044.e0b9c1adcff7503aa4e4d858430a66aa@haskell.org> References: <044.e0b9c1adcff7503aa4e4d858430a66aa@haskell.org> Message-ID: <059.88b9baac4aba97330a9f008886b08217@haskell.org> #8653: panic the impossible happened ---------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by guest): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 13:01:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 13:01:17 -0000 Subject: [GHC] #1978: Error message: Undefined reference to `XXX_closure' In-Reply-To: <045.20d18fd66d659649248435a8e2071ba7@haskell.org> References: <045.20d18fd66d659649248435a8e2071ba7@haskell.org> Message-ID: <060.c50fe676a557ccbbfdf3ba0eaafe72bf@haskell.org> #1978: Error message: Undefined reference to `XXX_closure' ----------------------------------------------+--------------------------- Reporter: Andriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC rejects valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------------+--------------------------- Changes (by MichalGajda): * status: closed => new * failure: => GHC rejects valid program * version: 6.6 => 7.4.1 * resolution: invalid => * architecture: x86 => arm Comment: Can replicate on armel (Raspberry Pi with Raspbian) - cabal install pandoc-1.11.1 gives: {{{ Linking dist/build/make-pandoc-man-pages/make-pandoc-man-pages ... dist/build/make-pandoc-man-pages/make-pandoc-man-pages-tmp/Main.o: In function `s7g3_info': /tmp/ghc15975_0/ghc15975_0.bc:(.text+0x3d64): undefined reference to `pandoczm1zi11zi1_TextziPandocziReadersziMarkdown_readMarkdown1_closure' dist/build/make-pandoc-man-pages/make-pandoc-man-pages-tmp/Main.o: In function `s7fm_info': /tmp/ghc15975_0/ghc15975_0.bc:(.text+0x3e4c): undefined reference to `pandoczm1zi11zi1_TextziPandocziReadersziMarkdown_readMarkdown2_closure' dist/build/make-pandoc-man-pages/make-pandoc-man-pages- tmp/Main.o:(.rodata+0x270): undefined reference to `pandoczm1zi11zi1_TextziPandocziReadersziMarkdown_readMarkdown1_closure' dist/build/make-pandoc-man-pages/make-pandoc-man-pages- tmp/Main.o:(.rodata+0x288): undefined reference to `pandoczm1zi11zi1_TextziPandocziReadersziMarkdown_readMarkdown2_closure' collect2: ld returned 1 exit status }}} I will try to construct a minimal test case in the following week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 13:01:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 13:01:58 -0000 Subject: [GHC] #1978: Error message: Undefined reference to `XXX_closure' In-Reply-To: <045.20d18fd66d659649248435a8e2071ba7@haskell.org> References: <045.20d18fd66d659649248435a8e2071ba7@haskell.org> Message-ID: <060.8fc610d18620cd0767cb6b5dead72026@haskell.org> #1978: Error message: Undefined reference to `XXX_closure' ----------------------------------------------+--------------------------- Reporter: Andriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC rejects valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------------+--------------------------- Comment (by MichalGajda): PS The same version of pandoc compiles on amd64 without any problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 13:02:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 13:02:55 -0000 Subject: [GHC] #8653: panic the impossible happened In-Reply-To: <044.e0b9c1adcff7503aa4e4d858430a66aa@haskell.org> References: <044.e0b9c1adcff7503aa4e4d858430a66aa@haskell.org> Message-ID: <059.e178c6e8e6b1961955fe8ce950b7b328@haskell.org> #8653: panic the impossible happened ---------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Already reported as #7389. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 13:05:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 13:05:47 -0000 Subject: [GHC] #7462: New nofib benchmark for unpacked arrays and floating point arithmetic In-Reply-To: <044.918937320119ec55bb5a7dd7a465ba45@haskell.org> References: <044.918937320119ec55bb5a7dd7a465ba45@haskell.org> Message-ID: <059.881cfe539b4d92f0e3380c8d2f10494f@haskell.org> #7462: New nofib benchmark for unpacked arrays and floating point arithmetic ------------------------------------------+-------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by hvr): Fyi, this benchmark is sensitive to wordsize, and as such currently makes the `nofib`-testsuite fail where `Word` is not 64bit wide. Shall we just use fixed-width types such as `Word64` in the code instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 13:09:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 13:09:10 -0000 Subject: [GHC] #7462: New nofib benchmark for unpacked arrays and floating point arithmetic In-Reply-To: <044.918937320119ec55bb5a7dd7a465ba45@haskell.org> References: <044.918937320119ec55bb5a7dd7a465ba45@haskell.org> Message-ID: <059.5e76be630b5094f198f938720c802fc8@haskell.org> #7462: New nofib benchmark for unpacked arrays and floating point arithmetic ------------------------------------------+-------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by tibbe): I don't think so. I think it should reflect the upstream shootout benchmark. Can't we just specify that it's intended result is different on 64-bit and 32-bit? I would have done it if I still had access to a 32-bit machine. (Testing Word64 on a 32-bit machine doesn't make sense as it's nothing we optimize for and thus it will always be awfully slow.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 13:13:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 13:13:17 -0000 Subject: [GHC] #7462: New nofib benchmark for unpacked arrays and floating point arithmetic In-Reply-To: <044.918937320119ec55bb5a7dd7a465ba45@haskell.org> References: <044.918937320119ec55bb5a7dd7a465ba45@haskell.org> Message-ID: <059.f7d1353da10f576f7b967de52d0442ef@haskell.org> #7462: New nofib benchmark for unpacked arrays and floating point arithmetic ------------------------------------------+-------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by hvr): Replying to [comment:5 tibbe]: > I don't think so. I think it should reflect the upstream shootout benchmark. Can't we just specify that it's intended result is different on 64-bit and 32-bit? Should be possible, I've seen something like that e.g. for {{{ ./real/scs/scs.stdout ./real/scs/scs.stdout-x86_64 ./real/scs/scs.stdout-x86-linux }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 14:37:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 14:37:50 -0000 Subject: [GHC] #7462: New nofib benchmark for unpacked arrays and floating point arithmetic In-Reply-To: <044.918937320119ec55bb5a7dd7a465ba45@haskell.org> References: <044.918937320119ec55bb5a7dd7a465ba45@haskell.org> Message-ID: <059.166015f3f907ebbfe6181dd5e4c082f6@haskell.org> #7462: New nofib benchmark for unpacked arrays and floating point arithmetic ------------------------------------------+-------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"e6759f06bfd067e18235017fd528e2e8d3b7b5c9/nofib"]: {{{ #!CommitTicketReference repository="nofib" revision="e6759f06bfd067e18235017fd528e2e8d3b7b5c9" Add Linux/x86 reference output for `kahan` benchmark This makes the nofib testsuite pass again when run on Linux/x86. See #7462 for more details Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 14:43:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 14:43:43 -0000 Subject: [GHC] #8654: Exponential-long compilation of code with Implicit params Message-ID: <046.9367f8983f76bd473ec848f143c0e80e@haskell.org> #8654: Exponential-long compilation of code with Implicit params -------------------------------------+------------------------------------- Reporter: akamaus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: ImplicitParams | Operating System: Unknown/Multiple slowness | Type of failure: Compile-time Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Some time ago I stumbled upon GHC hanging on my code. After some experiments I managed to minify it to: {-# LANGUAGE ImplicitParams #-} data D = D Int deriving Show slow_to_compile :: IO () slow_to_compile = do tst1 <- return 1 let ?tst1 = tst1 let ?tst2 = tst1 let ?tst3 = tst1 let ?tst4 = tst1 let ?tst5 = tst1 let ?tst6 = tst1 let ?tst7 = tst1 print $ D ?tst1 It compiles, but takes a while. Every additional binding doubles compilation time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 15:23:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 15:23:04 -0000 Subject: [GHC] #8654: Exponential-long compilation of code with Implicit params In-Reply-To: <046.9367f8983f76bd473ec848f143c0e80e@haskell.org> References: <046.9367f8983f76bd473ec848f143c0e80e@haskell.org> Message-ID: <061.335eae7a474d7d4b33b860b6639076ae@haskell.org> #8654: Exponential-long compilation of code with Implicit params -------------------------------------+------------------------------------- Reporter: akamaus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: duplicate | Keywords: ImplicitParams Operating System: Unknown/Multiple | slowness Type of failure: Compile-time | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: See #8474. It's fixed in the development branch (which will become 7.8). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 15:32:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 15:32:25 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks Message-ID: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> #8655: Evaluate know-to-terminate-soon thunks ------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I guess I?ll better put my interior monologue in a ticket than on ghc- dev... In order to implement nested CPR (#1600), I had to enrich the CPR type to keep track of whether something, when entered, will converge for sure. My code does not solve the halting problem, but does only simple stuff, so if something is known to converge, is is very likely to be cheap. Simon suggested to measure the effect of evaluating a let-bound thunk with the known-to-terminate property, as if the body was using it strictly. This tickets tracks this suggestion, and reports progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 15:41:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 15:41:38 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.15a6ff3d1dca9d24edd20b70b0492571@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): A first attempt looks promising: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- atom +0.0% -0.0% +0.7% +0.7% +0.0% binary-trees +0.0% +0.0% -0.4% -0.4% +0.0% cacheprof +0.0% +0.0% -0.8% +0.0% +0.0% circsim +0.0% +0.0% -2.7% -2.7% +0.0% constraints +0.0% +0.0% -1.3% -1.3% +0.0% cryptarithm1 +0.0% +0.0% -1.5% -1.0% +0.0% fannkuch-redux +0.0% +0.0% +0.1% +0.2% +0.0% fasta +0.0% +0.0% -0.6% +0.6% +0.0% hidden +0.0% +0.0% +0.0% +0.7% +0.0% integer +0.0% +0.0% +0.2% +0.2% +0.0% k-nucleotide +0.0% +0.0% -1.9% -1.9% +0.0% lcss +0.0% +0.0% -1.6% -0.8% +0.0% n-body +0.0% +0.0% -1.1% -1.1% +0.0% para +0.0% +0.0% -1.9% -2.8% +0.0% pidigits +0.0% +0.0% +0.0% -1.1% +0.0% power +0.0% +0.0% -2.9% -2.9% +0.0% scs +0.0% +0.0% +0.0% +0.0% +0.0% spectral-norm +0.0% +0.0% +0.2% +0.2% +0.0% transform +0.0% +0.0% -1.8% -1.8% +0.0% wave4main +0.0% +0.0% -1.9% -1.0% +0.0% wheel-sieve1 +0.0% +0.0% +0.8% +0.8% +0.0% -------------------------------------------------------------------------------- Min -0.0% -0.1% -2.9% -2.9% -17.4% Max +0.0% +0.0% +0.8% +0.8% +0.0% Geometric Mean -0.0% -0.0% -0.9% -0.7% -0.2% }}} Such a speculative optimization cannot be expected to be a definite win, but I think the numbers are encouraging: No large increase and a detectable improvement in the mean. I put my code in `wip/cbv-conv-thunk`, which shares some patches with `wip /nested-cpr` that are not in master yet. Let?s see how that goes for a rebasing branch... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 16:19:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 16:19:42 -0000 Subject: [GHC] #8648: Initialization of C statics broken in threaded runtime In-Reply-To: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> References: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> Message-ID: <059.a105576fa2be819d84382c2f83ed0e6c@haskell.org> #8648: Initialization of C statics broken in threaded runtime -------------------------------------+------------------------------------ Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by duncan): Also note that it works when the `static-value` package is built as a dynamic lib and the top level exe uses dynamic libs. So what it looks like is that the ghci linker is not zeroing the memory allocated for the zero-init section from the object files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 17:34:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 17:34:56 -0000 Subject: [GHC] #8622: Importing modules in .ghci file doesn't work In-Reply-To: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> References: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> Message-ID: <060.94d20bce885adf9cb98a5707bec49123@haskell.org> #8622: Importing modules in .ghci file doesn't work ---------------------------------+---------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by m4dc4p): * status: new => closed * resolution: => invalid Comment: Thanks for taking a look - I've marked this bug as invalid, since its by design. Hope that is the right process! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 22:53:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 22:53:16 -0000 Subject: [GHC] #5361: regSpill: out of spill slots! In-Reply-To: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> References: <049.cbc3b6a1173f092cb2619a218adec7c2@haskell.org> Message-ID: <064.dcfee95de836f9b9dc04133f20d24d17@haskell.org> #5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: regSpill panic Operating System: Linux | impossible Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: http://hackage.haskell.org/package/SHA| Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by carter): indeed, changing a compiler flag is a work around, not a fix. So its ameliorated for 7.8, but can we really consider this "fixed" ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 6 23:14:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Jan 2014 23:14:45 -0000 Subject: [GHC] #1978: Error message: Undefined reference to `XXX_closure' In-Reply-To: <045.20d18fd66d659649248435a8e2071ba7@haskell.org> References: <045.20d18fd66d659649248435a8e2071ba7@haskell.org> Message-ID: <060.27f70ea0fab8a86e8268a054b73bc91c@haskell.org> #1978: Error message: Undefined reference to `XXX_closure' ----------------------------------------------+--------------------------- Reporter: Andriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC rejects valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------------+--------------------------- Comment (by MichalGajda): Here is a patch that fixed the issue in Pandoc, to give idea how it looks: {{{ diff -u -r orig/pandoc-1.11.1/src/Text/Pandoc/Readers/Markdown.hs pandoc-1.11.1/src/Text/Pandoc/Readers/Markdown.hs --- orig/pandoc-1.11.1/src/Text/Pandoc/Readers/Markdown.hs 2014-01-06 23:09:47.928990710 +0000 +++ pandoc-1.11.1/src/Text/Pandoc/Readers/Markdown.hs 2014-01-06 21:33:46.963590240 +0000 @@ -63,7 +63,10 @@ -> String -- ^ String to parse (assuming @'\n'@ line endings) -> Pandoc readMarkdown opts s = - (readWith parseMarkdown) def{ stateOptions = opts } (s ++ "\n\n") + readWithParser def { stateOptions = opts } (s ++ "\n\n") + +-- | Helper function to avoid missing closure bug. See GHC bug #1978 +readWithParser state s = readWith parseMarkdown state s -- | Read markdown from an input string and return a pair of a Pandoc document -- and a list of warnings. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 02:01:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 02:01:02 -0000 Subject: [GHC] #1978: Error message: Undefined reference to `XXX_closure' In-Reply-To: <045.20d18fd66d659649248435a8e2071ba7@haskell.org> References: <045.20d18fd66d659649248435a8e2071ba7@haskell.org> Message-ID: <060.d61d33afe793bcde11d85c436e35f9c7@haskell.org> #1978: Error message: Undefined reference to `XXX_closure' ----------------------------------------------+--------------------------- Reporter: Andriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC rejects valid program | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------------+--------------------------- Comment (by carter): huh, have you tested with GHC head? Is it resolved in 7.7 currently? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 09:10:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 09:10:27 -0000 Subject: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function In-Reply-To: <047.d854a286f40f24efedada1697ad637ee@haskell.org> References: <047.d854a286f40f24efedada1697ad637ee@haskell.org> Message-ID: <062.9593473728fad7a2e6810e21209d5d96@haskell.org> #1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by NeilMitchell): http://neilmitchell.blogspot.co.uk/2014/01/optimising-haskell-for-tight- inner-loop.html - the code in version 4/version 5 includes a small example of the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 09:50:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 09:50:52 -0000 Subject: [GHC] #8656: Identical functions in Templeta Haskell Message-ID: <048.2ac272abe3740e215f6c78d1cb63e458@haskell.org> #8656: Identical functions in Templeta Haskell -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- I noticed that module `Language.Haskell.TH.Lib` in template-haskell library contains duplicate functions: {{{ global :: Name -> ExpQ global s = return (VarE s) varE :: Name -> ExpQ varE s = return (VarE s) }}} If this is intended it should be documented why it is so and I think it would be good to express one function in terms of another. If this is accidental we should just get rid of one function. I never used TH so I have no idea whether this is done on purpose or not, thus leaving it to devs more experienced with TH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 10:11:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 10:11:36 -0000 Subject: [GHC] #5075: CPR optimisation for sum types if only one constructor is used In-Reply-To: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> References: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> Message-ID: <068.8946ec9d0a21285d73f1a5146c3a634a@haskell.org> #5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): In that case, let me add some numbers related to sum type CPR in local functions. With current master [4d70840d/ghc], enabling CPR for sum types has this effect: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi +8.6% +0.5% 0.00 0.00 +0.0% awards +8.6% +0.2% 0.00 0.00 +0.0% cacheprof +8.0% +0.2% -3.1% -3.1% +0.0% calendar +8.6% +0.2% 0.00 0.00 +0.0% circsim +8.5% +1.1% -8.7% -8.7% -2.0% cryptarithm1 +8.7% -3.8% +0.5% +0.5% +0.0% cse +8.6% +0.2% 0.00 0.00 +0.0% fibheaps +8.6% -0.3% 0.02 0.02 +0.0% fluid +7.7% +3.4% 0.01 0.01 +0.0% fulsom +8.3% +0.1% 0.19 0.19 -31.2% hidden +8.3% +1.8% +3.4% +6.2% +0.0% kahan +8.1% +0.1% 0.17 0.17 +0.0% listcompr +8.6% +0.4% 0.06 0.05 +0.0% listcopy +8.6% +0.4% 0.07 0.06 +0.0% mandel +7.5% +0.3% 0.05 0.05 +0.0% mandel2 +8.7% +33.8% 0.00 0.00 +0.0% parser +8.1% +1.7% 0.02 0.02 +0.0% primetest +8.7% -0.2% 0.07 0.07 +0.0% reptile +8.5% +0.2% 0.01 0.01 +0.0% rewrite +8.5% +0.1% 0.02 0.02 +0.0% rfib +8.7% +0.6% 0.02 0.02 +0.0% spectral-norm +8.5% +0.7% -0.6% -0.6% +0.0% symalg +8.3% +0.2% 0.01 0.01 +0.0% tak +8.6% +1.3% 0.01 0.01 +0.0% transform +8.3% +0.1% +0.0% +0.0% +0.0% -------------------------------------------------------------------------------- Min +6.8% -3.8% -11.3% -11.3% -31.2% Max +8.7% +33.8% +3.9% +6.2% +6.1% Geometric Mean +8.4% +0.4% -1.8% -1.8% -0.4% }}} So one quite extreme degradation, and otherwise minor losses. If I make sure that join points do not get the CPR information unless the expression they are a join point for does, we get this change (relative to the same baseline): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof +8.0% +0.3% -4.7% -4.7% +1.8% calendar +8.6% +0.1% 0.00 0.00 +0.0% circsim +8.5% +0.2% -8.4% -8.4% -2.0% cryptarithm1 +8.6% -3.8% +1.5% +1.5% +0.0% cse +8.6% +0.2% 0.00 0.00 +0.0% fibheaps +8.5% -0.3% 0.03 0.03 +0.0% fulsom +8.2% -3.7% 0.19 0.19 -31.2% kahan +8.1% -0.2% 0.17 0.17 +0.0% listcompr +8.6% +0.4% 0.07 0.06 +0.0% listcopy +8.6% +0.4% 0.07 0.06 +0.0% maillist +8.6% +0.0% 0.04 0.04 +16.0% mandel +7.4% +0.2% 0.05 0.05 +0.0% parser +8.1% +1.7% 0.02 0.02 +0.0% primetest +8.6% -0.2% 0.07 0.07 +0.0% rewrite +8.5% +0.1% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min +6.8% -3.8% -8.4% -8.4% -31.2% Max +8.7% +1.7% +3.2% +3.4% +16.0% Geometric Mean +8.3% -0.0% -2.0% -1.9% -0.2% }}} This looks quite different now: A few losses, but much smaller than before. A mean of zero, and more gains than before. Unfortunately, the code size increase is still there... If it were not for the code size increase, I?d suggest to merge these changes: Fewer special cases in transformations is a good thing. But it is probably not worth the code size increase, is it? (Just for the record: In theory it is possible that CPR?ing a non-sum-type can destroy the join-point-property of a let. But it does not seem to happen: If I enable the cpr-join-point-fix, but keep CPR for sum types disabled, nofib does not record any change whatsoever.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 10:23:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 10:23:53 -0000 Subject: [GHC] #5075: CPR optimisation for sum types if only one constructor is used In-Reply-To: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> References: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> Message-ID: <068.08f1875a548df3a51b856d39bb13ee88@haskell.org> #5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): An 8% increase in binary size is pretty dramatic. I wonder why that is happening. (Not every easy to find out.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 10:49:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 10:49:53 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.f414adcab9fab1782be9622a248fb68d@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): (Hmm, on second thought: I guess for Runtime, these numbers are below nofib?s precision... So maybe the gain is simply zero? The unchanged allocations seem to support that.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 11:40:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 11:40:30 -0000 Subject: [GHC] #5498: Generalized newtype deriving allows creating of instances I can't create by hand In-Reply-To: <045.07b11c8f532229ab6848cf0b72e86f9b@haskell.org> References: <045.07b11c8f532229ab6848cf0b72e86f9b@haskell.org> Message-ID: <060.e6f8724009907497bb749d8a8f114f63@haskell.org> #5498: Generalized newtype deriving allows creating of instances I can't create by hand -------------------------------------+------------------------------------ Reporter: dterei | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 1496 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: This should not be possible any more: In the type `intIso :: forall c. c t -> c Int`, `c`?s type parameter is considered to be nominal, so `coerce` will not allow changing `c (Down a)` to `c a` any more. And GND is now based on `Coercible`... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 12:14:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 12:14:46 -0000 Subject: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function In-Reply-To: <047.d854a286f40f24efedada1697ad637ee@haskell.org> References: <047.d854a286f40f24efedada1697ad637ee@haskell.org> Message-ID: <062.ad5064c8dd8054e2746e02e6a1784019@haskell.org> #1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: 4258 Blocking: | Related Tickets: 8326 -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => 8326 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 12:22:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 12:22:40 -0000 Subject: [GHC] #5498: Generalized newtype deriving allows creating of instances I can't create by hand In-Reply-To: <045.07b11c8f532229ab6848cf0b72e86f9b@haskell.org> References: <045.07b11c8f532229ab6848cf0b72e86f9b@haskell.org> Message-ID: <060.706ff3b7a02691ab4120e661726ab2fe@haskell.org> #5498: Generalized newtype deriving allows creating of instances I can't create by hand -----------------------------------------------+--------------------------- Reporter: dterei | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: deriving/should_fail/T5498 | Difficulty: Unknown Blocking: | Blocked By: 1496 | Related Tickets: -----------------------------------------------+--------------------------- Changes (by simonpj): * testcase: => deriving/should_fail/T5498 Comment: Indeed. The program is indeed rejected, although the error message is not fantastic. I've added it as a test. I think you can enable GND in Safe Haskell. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 12:50:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 12:50:23 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.5450bf65cac5384c83c16cfb1dd8b602@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Indeed, after running before and after again, and making sure the machine does nothing else in that time, I get {{{ Min -0.0% -0.1% -2.2% -1.6% -1.3% Max +0.0% +0.0% +3.6% +3.6% +9.7% Geometric Mean -0.0% -0.0% +0.2% +0.3% +0.1% }}} So probably it?s not worth it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 13:39:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 13:39:30 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.5f4f5b227f35059523fa8b568e9c60b7@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Try running the shootout benchmarks in "slow" mode. They have been tuned to have meaningful runtimes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:30:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:30:07 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.749a56e3164a2888c3b7ea5d9f0e5ca7@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"e25af05656b496b997c8f3520e5ac8e377a68e7b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e25af05656b496b997c8f3520e5ac8e377a68e7b" Fix -dynamic-too clashing with -o (#8180) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:30:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:30:08 -0000 Subject: [GHC] #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) In-Reply-To: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> References: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> Message-ID: <065.ded2254566e2c1e3e5a52cf77cb39d6e@haskell.org> #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) ---------------------------------------+----------------------------------- Reporter: SimonHengel | Owner: hellertime Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Austin Seipp ): In [changeset:"032969f7c7493d774958e65e61690bd2a995fbbc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="032969f7c7493d774958e65e61690bd2a995fbbc" Re-order preprocessor args to agree with User Guide (fixes #8602) The section of the User Guide in reference is 4.12.4 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:30:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:30:11 -0000 Subject: [GHC] #8601: runghc from standard input and --ghc-args In-Reply-To: <045.11cb225cfe1bdf84af2a31b9e73fe50d@haskell.org> References: <045.11cb225cfe1bdf84af2a31b9e73fe50d@haskell.org> Message-ID: <060.ddd031e20a15162640058214f96aa1e2@haskell.org> #8601: runghc from standard input and --ghc-args -------------------------------------+------------------------------------ Reporter: wuzzeb | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"ec4af3fbcd47ca3af1727e70fa20e7cb8db0fb41/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ec4af3fbcd47ca3af1727e70fa20e7cb8db0fb41" runghc: Fix interaction of stdin and --ghc-args When reading the program from standard input, runghc did not properly handle the --ghc-arg= escape for arguments to ghc which do not start with a dash, since arguments were processed twice and the first time the --ghc-arg= was stripped. Now arguments are only processed once. For backwards compatibility, a prefix of --ghc-arg=--ghc-arg= is allowed since this prefix will work on both old and new versions of ghc. This fixes #8601 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:31:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:31:00 -0000 Subject: [GHC] #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) In-Reply-To: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> References: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> Message-ID: <065.0937dececc8dc86e4846671d6fe9f7de@haskell.org> #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) ---------------------------------------+----------------------------------- Reporter: SimonHengel | Owner: hellertime Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Austin Seipp ): In [changeset:"b7bc064e3cdd439eb54bc6f978a067aa2eef7927/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="b7bc064e3cdd439eb54bc6f978a067aa2eef7927" Add test suite for #8602 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:31:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:31:01 -0000 Subject: [GHC] #8601: runghc from standard input and --ghc-args In-Reply-To: <045.11cb225cfe1bdf84af2a31b9e73fe50d@haskell.org> References: <045.11cb225cfe1bdf84af2a31b9e73fe50d@haskell.org> Message-ID: <060.6a4b944d21f06e0084dedcbad10374b1@haskell.org> #8601: runghc from standard input and --ghc-args -------------------------------------+------------------------------------ Reporter: wuzzeb | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"f50c270457a2b9fbf831ab53081e111c84156bf9/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="f50c270457a2b9fbf831ab53081e111c84156bf9" Tests for #8601 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:31:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:31:36 -0000 Subject: [GHC] #8102: Parallel build of HEAD consistently fails In-Reply-To: <044.d6679f8dfedc0d08d438a0c928eb9fe9@haskell.org> References: <044.d6679f8dfedc0d08d438a0c928eb9fe9@haskell.org> Message-ID: <059.5fe79435d30b4529629b45ce21bc658e@haskell.org> #8102: Parallel build of HEAD consistently fails -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"8ed8ac58b4a5c8654fccee4436ca62bf7c690474/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="8ed8ac58b4a5c8654fccee4436ca62bf7c690474" Hackishly fix parallel build failure with in-tree GMP See the comments and #8102. The basic gist of it seems to be that the build system follows an implied rule from somewhere to directly build a C file, which doesn't have a dependency on the in-tree gmp.h that we build. As a result, the C file compilation races against the GMP build, causing an error. This is a pretty unsatisfactory hack, but for Windows and OS X machines where we more often build in-tree GMPs, it's quite important. Authored-by: Kazu Yamamoto Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:34:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:34:03 -0000 Subject: [GHC] #8102: Parallel build of HEAD consistently fails In-Reply-To: <044.d6679f8dfedc0d08d438a0c928eb9fe9@haskell.org> References: <044.d6679f8dfedc0d08d438a0c928eb9fe9@haskell.org> Message-ID: <059.bbefb5d6cfb0b6a7e43bcc08ebcbfd82@haskell.org> #8102: Parallel build of HEAD consistently fails -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * priority: normal => high * status: patch => infoneeded * milestone: => 7.10.1 Comment: Kazu, I merged your patch because after some debugging, I couldn't figure out the problem still. In the mean time, this will help Windows and OS X builds until I can pin down the real problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:34:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:34:27 -0000 Subject: [GHC] #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. In-Reply-To: <044.489edd9a621286a2f23856fcc4df99d4@haskell.org> References: <044.489edd9a621286a2f23856fcc4df99d4@haskell.org> Message-ID: <059.0909d57a174c7065c68df0899f3b3178@haskell.org> #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:35:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:35:01 -0000 Subject: [GHC] #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) In-Reply-To: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> References: <050.0f96b843acaeec89e0eea7d9a48c58ce@haskell.org> Message-ID: <065.c59520f7db97a2b65eeda580d9569479@haskell.org> #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) ---------------------------------------+----------------------------------- Reporter: SimonHengel | Owner: hellertime Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:35:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:35:07 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.319bb27bfadd87f9faf3ea402b8754b3@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks Ben! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:36:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:36:04 -0000 Subject: [GHC] #8601: runghc from standard input and --ghc-args In-Reply-To: <045.11cb225cfe1bdf84af2a31b9e73fe50d@haskell.org> References: <045.11cb225cfe1bdf84af2a31b9e73fe50d@haskell.org> Message-ID: <060.106a40123f5cc6de25d60ec2e8e1b1e7@haskell.org> #8601: runghc from standard input and --ghc-args -------------------------------------+------------------------------------ Reporter: wuzzeb | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged (with a fixed test.) Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:48:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:48:18 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.bef7ab76159ebdc67ddb0f26b62c161c@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): I've fixed the clash between `-o` and `-dynamic-too`, so now when you say: {{{ ghc -dynamic-too Main.hs }}} the inferred file names should be appropriately generated. The rule is that if you're specifying `-o` but not `-dyno`, then the `-dyno` name should simply be the same filename, but with the dynamic object extension. (Note this doesn't affect linking executables - `-dyno` has no effect there.) I'm now looking to finish the other half (enable `-dynamic-too` if we detect `-XTemplateHaskell` during module loading,) but my first-try patch doesn't seem to work yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 14:53:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 14:53:29 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.59dcb97d87f89974b983205f585971db@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files --------------------------------------------+------------------------------ Reporter: ezyang | Owner: Type: bug | thoughtpolice Priority: highest | Status: new Component: Compiler | Milestone: 7.8.1 Resolution: | Version: 7.7 Operating System: Windows | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: cabal01 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #7134 --------------------------------------------+------------------------------ Comment (by thoughtpolice): The most bizarre aspect of this ticket now that I'm looking at it more deeply is that if you don't use `--make`, i.e. you're using one-shot mode, then GHC does indeed seem to generate dynamic interface files successfully. I have no idea why `--make` mode would be any different (yet) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 15:03:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 15:03:21 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.93e06944eadd87c6ec0864242f21ee09@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Thanks for the suggestion. Two new runs, unloaded machine, slow mode. Slightly different numbers, but encouraging again: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi +0.0% +0.0% +0.3% +0.5% +0.0% atom +0.0% -0.0% +0.6% +0.6% +0.0% binary-trees +0.0% +0.0% +0.0% -0.0% +0.0% boyer +0.0% +0.0% -0.5% -0.5% +0.0% cacheprof +0.0% -0.2% -1.6% -1.6% +0.9% calendar +0.0% +0.0% -0.7% -0.7% +0.0% circsim +0.0% +0.0% -0.9% -1.2% +0.0% clausify +0.0% +0.0% +0.6% +0.6% +0.0% comp_lab_zift +0.0% +0.0% +0.7% +0.0% +0.0% constraints +0.0% +0.0% -0.3% -0.4% +0.0% cryptarithm1 +0.0% +0.0% -0.5% -0.5% +0.0% event +0.0% +0.0% +0.0% +0.0% +0.0% exp3_8 +0.0% +0.0% +0.0% +0.0% +0.0% fannkuch-redux +0.0% +0.0% +0.0% +0.0% +0.0% fasta +0.0% +0.0% +0.2% +0.2% +0.0% fft +0.0% +0.0% -0.8% -0.8% +0.0% fibheaps +0.0% +0.0% -3.0% -3.0% +0.0% fluid -0.0% -0.1% 0.01 0.01 +0.0% gen_regexps +0.0% +0.0% -1.2% -0.4% +0.0% genfft +0.0% +0.0% -2.2% +0.0% +0.0% hidden +0.0% +0.0% +0.0% +0.0% +0.0% ida +0.0% +0.0% +0.0% +0.0% +0.0% integer +0.0% +0.0% -0.2% -0.2% +0.0% integrate +0.0% +0.0% -0.9% -0.9% +0.0% k-nucleotide +0.0% +0.0% -0.4% -0.4% +0.0% kahan +0.0% +0.0% +1.2% +1.2% +0.0% knights +0.0% +0.0% +0.0% +0.0% +0.0% lcss +0.0% +0.0% -1.9% -1.9% +0.0% multiplier +0.0% +0.0% -0.4% -0.4% +0.0% n-body +0.0% +0.0% -0.6% -0.6% +0.0% para +0.0% +0.0% +0.0% +0.0% +0.0% paraffins +0.0% +0.0% -3.3% -2.9% +0.0% pidigits +0.0% +0.0% +0.2% +0.4% +0.0% power +0.0% +0.0% -0.6% -0.6% +0.0% primes +0.0% +0.0% -0.4% -0.4% +0.0% queens +0.0% +0.0% +0.0% +0.0% +0.0% reverse-complem +0.0% +0.0% +0.0% +0.3% +0.0% rewrite +0.0% +0.0% +1.7% +2.5% +0.0% sched +0.0% +0.0% +0.3% +0.3% +0.0% scs +0.0% +0.0% +0.5% +0.5% +0.0% solid +0.0% +0.0% -0.6% -0.6% +0.0% spectral-norm +0.0% +0.0% +0.0% -0.1% +0.0% tak +0.0% +0.0% +0.7% +0.7% +0.0% transform +0.0% +0.0% +0.0% +0.0% +0.0% typecheck -0.0% +0.0% -0.7% -0.7% +0.0% wang +0.0% +0.0% -1.1% -1.1% +0.0% wave4main +0.0% +0.0% +0.0% +0.0% +0.0% wheel-sieve1 +0.0% +0.0% +0.0% +0.0% +0.0% wheel-sieve2 +0.0% +0.0% -3.3% -4.1% +0.0% -------------------------------------------------------------------------------- Min -0.0% -0.2% -3.3% -4.1% -19.3% Max +0.0% +0.0% +1.7% +2.5% +0.9% Geometric Mean -0.0% -0.0% -0.4% -0.3% -0.2% }}} I?m still a bit surprised that allocations do not change ? but at least they change for `fluid`, so maybe I am not measuring noise after all :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 15:35:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 15:35:57 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.76cbdd273b7d650c8df7010eae964958@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Changes (by hvr): * status: new => patch Comment: I attached the patch instead of pushing to Git, as I'm not satisfied yet with it. It's works stable here (passes `validate` & `nofib`), but I'm not sure about the `unsafeCoerce#`. In my first version of this patch, I used a 3-tuple `(# Int#, ByteArray#, Word# #)` as return value, but that wasted 1 return register per `Integer` result, and still had to return a NULL pointer for `ByteArray#` for the case it wasn't used. I'm wondering if it would be feasible and sensible to return a properly constructed `Integer` value from the Cmm wrappers (i.e. to fold `tupToInteger` into gmp-`wrappers.cmm`), but I haven't figured out yet how to implement that in Cmm. Moreover, I'm also still wondering how to properly allocate stack-space in "high-level" Cmm procedures (see [http://www.haskell.org/pipermail/ghc- devs/2014-January/003616.html posting on ghc-devs@]), as the current code seems to work properly only as long the Cmm procedures don't force the code generator to save registers to the stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 15:58:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 15:58:21 -0000 Subject: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function In-Reply-To: <047.d854a286f40f24efedada1697ad637ee@haskell.org> References: <047.d854a286f40f24efedada1697ad637ee@haskell.org> Message-ID: <062.986736aeafcd708030fb56bd47edaa03@haskell.org> #1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: 4258 Blocking: | Related Tickets: 8326 -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 18:34:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 18:34:20 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.ea521681f897fab3cb8d4762b6b4feb5@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I don't know if slow mode is really for anything but the shootout benchmarks though, so pay closer attention to those results above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 21:07:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 21:07:39 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.9bcd81a8772bb3887940581dc9d91111@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:6 hvr]: > I attached the patch instead of pushing to Git, as I'm not satisfied yet with it. It's works stable here (passes `validate` & `nofib`), but I'm not sure about the `unsafeCoerce#`. > > In my first version of this patch, I used a 3-tuple `(# Int#, ByteArray#, Word# #)` as return value, but that wasted 1 return register per `Integer` result, and still had to return a NULL pointer for `ByteArray#` for the case it wasn't used. After a conversation with Duncan, I'm now convinced that the `(# Int#, ByteArray# #)` + `unsafeCoerce#` hack is really bad, as the GC could try to follow the `ByteArray#` pointer even though it was really just a `Word#` in disguise. Otoh, passing a 0-pointer for the 3-tuple variant has the same danger. So now I'm left wondering if I can somehow statically allocate a dummy `ByteArray#` I can return in Cmm when there's no need to allocate a proper `ByteArray#` in order to avoid confusing the GC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 7 21:42:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Jan 2014 21:42:15 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.74c92bb5c5239f3e8a6d91bc944d13bf@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Changes (by kgardas): * owner: => kgardas Comment: Nobody stepped forward so far on this, so I'd like to give it a try myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 02:29:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 02:29:35 -0000 Subject: [GHC] #551: "No threads to run" ignores finalizers In-Reply-To: <043.41adf93cf0862836ae08b16b8b251c93@haskell.org> References: <043.41adf93cf0862836ae08b16b8b251c93@haskell.org> Message-ID: <058.01f057889fd6a4cd9c2aef45ccbe03aa@haskell.org> #551: "No threads to run" ignores finalizers -------------------------------------+------------------------------------ Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 5.0 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * status: closed => new * failure: => None/Unknown * cc: simonmar (added) * resolution: Fixed => * difficulty: => Unknown * architecture: => Unknown/Multiple * owner: simonmar => * os: => Unknown/Multiple Old description: > {{{ > This is re my posting under the subject "Weak pointers, > garbage collection & deadlocks" on > glasgow-haskell-users. > > Basically, the problem is that finaliser threads that > the next GC would generate aren't taken into account > when determining whether there are any more threads to > run. > > I attach a program reproducing the error. > }}} New description: {{{ This is re my posting under the subject "Weak pointers, garbage collection & deadlocks" on glasgow-haskell-users. Basically, the problem is that finaliser threads that the next GC would generate aren't taken into account when determining whether there are any more threads to run. I attach a program reproducing the error. }}} -- Comment: Reopening as per previous commit message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 06:54:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 06:54:14 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.68eaefc60aa466c4e377ab761dd58af2@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): kgardas, its kinda gated on first doing some NCG cleanup, (because theres a lot of copy pasta logic across the current NCG backends, and improving the engineering niceness of NCG will make such easier). please feel welcome to hack out a prototype if you have the time, but please keep in mind that it may be easier after first cleaning up and refactoring NCG. I *hope* to have the time to start hacking on that refactoring end of january onwards, though i hope other people collab on it too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 06:58:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 06:58:09 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.4cb5dffd5be3e8a7734b54004b0ba5aa@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): adding LLVM AARCH64 support would be great for GHC-IOS too. please reach out on ghc-devs / #ghc if you hit any problems or need any help -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 08:49:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 08:49:41 -0000 Subject: [GHC] #551: "No threads to run" ignores finalizers In-Reply-To: <043.41adf93cf0862836ae08b16b8b251c93@haskell.org> References: <043.41adf93cf0862836ae08b16b8b251c93@haskell.org> Message-ID: <058.5759821b8b36f49612754f036593601c@haskell.org> #551: "No threads to run" ignores finalizers -------------------------------------+------------------------------------ Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 5.0 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: We shouldn't consider this a bug, since we deliberately decided to go with the alternative behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 09:25:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 09:25:47 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.2ba6ff8d6d297d67f55088180c7b724f@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by kgardas): I'm following the same way like Stephen/David/me did ARM in the past: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting NCG way makes sense once you do have LLVM working, then you can try -fasm on smallest examples and do it step-by-step with increased example complexity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 10:32:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 10:32:42 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots Message-ID: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> #8657: -fregs-graph still has a limit on spill slots -----------------------------------+--------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The limit on spill slots was removed for the linear register allocator in 7.8, but not for `-fregs-graph`. SHA-1 fails to compile with `-fregs-graph` in 7.8. Related: #7679 (`-fregs-graph` generates poor code with the new codegen). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 10:32:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 10:32:58 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.2d9b7530d5ee73eb049f5e8ae59c4b35@haskell.org> #8657: -fregs-graph still has a limit on spill slots ---------------------------------------+----------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 7679 ---------------------------------------+----------------------------------- Changes (by simonmar): * related: => 7679 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 10:33:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 10:33:19 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.c256d9205beb46b576dac370a3b1b70f@haskell.org> #8657: -fregs-graph still has a limit on spill slots ---------------------------------------+----------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7679 ---------------------------------------+----------------------------------- Changes (by simonmar): * related: 7679 => #7679 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 10:33:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 10:33:43 -0000 Subject: [GHC] #7679: Regression in -fregs-graph performance In-Reply-To: <047.9e26897513125de7441d596a4b30ee54@haskell.org> References: <047.9e26897513125de7441d596a4b30ee54@haskell.org> Message-ID: <062.4641c9f2ac154a14c4b67932a91f1f90@haskell.org> #7679: Regression in -fregs-graph performance --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7192, | #8657 --------------------------------------------+------------------------------ Changes (by simonmar): * cc: simonmar (added) * related: #7192 => #7192, #8657 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 10:34:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 10:34:51 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.712bf13cbcf3fcd65cf18017419b7d01@haskell.org> #8657: -fregs-graph still has a limit on spill slots ---------------------------------------+----------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7679 ---------------------------------------+----------------------------------- Changes (by simonmar): * priority: normal => highest Comment: For 7.8.1 we should probably disable `-fregs-graph` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 10:57:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 10:57:50 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.ba1d5ae2552bc28e9c4ba818a2da5dcd@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): The latest patch makes Mach-O (currently just Darwin, not iOS) behave the same as ELF in terms of dynamic linking. That is, all dynamic library locations are now relative to `@rpath`, and GHC adds `LC_RPATH` commands for every directory containing the dependent libraries. This enables the use-case of using `cabal -w inplace/bin/ghc-stage2`. Cabal will however need an update as well, as libraries installed by Cabal will still use absolute paths: {{{ -- Installed by GHC install @rpath/package1.dylib @rpath/package2.dylib @rpath/package3.dylib -- Installed by Cabal /absolute_path_to_library/package4.dylib /absolute_path_to_library/package5.dylib }}} By applying the following patch to Cabal: {{{ diff --git a/Cabal/Distribution/Simple/GHC.hs b/Cabal/Distribution/Simple/GHC.hs index c7ea633..78cdcbb 100644 --- a/Cabal/Distribution/Simple/GHC.hs +++ b/Cabal/Distribution/Simple/GHC.hs @@ -867,11 +867,6 @@ buildOrReplLib forRepl verbosity pkg_descr lbi lib clbi = do ghcOptDynLinkMode = toFlag GhcDynamicOnly, ghcOptInputFiles = dynamicObjectFiles, ghcOptOutputFile = toFlag sharedLibFilePath, - -- For dynamic libs, Mac OS/X needs to know the install location - -- at build time. - ghcOptDylibName = if buildOS == OSX - then toFlag sharedLibInstallPath - else mempty, ghcOptPackageName = toFlag pkgid, ghcOptNoAutoLinkPackages = toFlag True, ghcOptPackageDBs = withPackageDB lbi, }}} The situation will change to: {{{ -- Installed by GHC install @rpath/package1.dylib @rpath/package2.dylib @rpath/package3.dylib -- Installed by Cabal @rpath/package4.dylib @rpath/package5.dylib }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 16:04:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 16:04:41 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.aa88facfb3a32291cbd4cce78c1ddd38@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): (Update to sidenote: inlining `runSTRep` may allow it to get a `CPR` property, but this does not magically help with join-points, also see [wiki:NestedCPR/wave4main]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 16:36:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 16:36:12 -0000 Subject: [GHC] #5916: runST isn't free In-Reply-To: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> References: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> Message-ID: <059.118cd95e3b9242d003884002cf46e92b@haskell.org> #5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Just noting down some id?e fixe: The reason we are not inlining `runSTRep` is that we don?t want to expressions using the `realWorld#` token to become shared, right? How about `runSTRep` gets a special inlining that mentions all free variables of its argument, using a special token of type `stWorld# :: a -> RealWorld#`. So `runSTRep (f x (z x))` would get unfolded to {{{ case f x (z x) (stWorld# (f,x,z)) of (# _, r #) -> r }}} The variables mentioned in `stWorld?s` argument prevent this from being floated out, and I believe it ouldn?t that solve tibbe?s problem, right? It might also enable more CPR-related optimizations. When generating `STG`, the argument of `stWorld#` would of course be ignored. (In fact, it seems it would be correct ot have `runSTRep e = case e (stWorld# e) of (# _, #r) -> r`, which could be formulated as a plain `RULE`, but that would blow up the core expressions during compilation too much, I?d expect.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 17:04:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 17:04:24 -0000 Subject: [GHC] #3373: GHC API is not thread safe In-Reply-To: <049.05da201065b7c5ade7dcf13301c3e81b@haskell.org> References: <049.05da201065b7c5ade7dcf13301c3e81b@haskell.org> Message-ID: <064.96272be0892868ff5557a1c30fa00084@haskell.org> #3373: GHC API is not thread safe -------------------------------------+------------------------------------ Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.10.1 Component: GHC API | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by lelf): * cc: me@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 17:23:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 17:23:42 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.a9430210ba95422f2d5f0b7174e5e6d9@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): sounds reasonable. Will the arm 32 bit ghc calling convention make sense for AArch64? We may need to get a patch into llvm before having a distinct aarch64 abi. (and we shoudl probably do some pretty thorough benchmarking before picking any such ABI) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 17:53:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 17:53:45 -0000 Subject: [GHC] #5916: runST isn't free In-Reply-To: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> References: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> Message-ID: <059.a2b0a131992e4b1bdfb7e775ea1b0262@haskell.org> #5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Using {{{#!haskell {-# INLINE runSTRep #-} runSTRep :: (forall s. STRep s a) -> a runSTRep st_rep = case st_rep (stWorld# st_rep) of (# _, r #) -> r {-# NOINLINE stWorld# #-} stWorld# :: a -> State# RealWorld stWorld# _ = realWorld# }}} it validates. But do we actually have a test for this? Here would be one: {{{#!haskell import Control.Monad.ST import Data.STRef main = let f n = runST $ do ref <- newSTRef 0 modifySTRef ref (+n) readSTRef ref in print (f 1 + f 2) }}} returns 3 in master, returns 4 if I inline `runSTRep`, and returns 3 with the `stWorld#`-trick. So unless someone says that this is not worth it (which would be strange, given that this bug is about an unexpected real-world performance issue), I suggest to give `runSTRep` a custom unfolding in `MkId` that replaces `runSTRep e` by `case e (stWorld# $(all free local variables of e)) of (# _, r #) -> r`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 17:54:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 17:54:29 -0000 Subject: [GHC] #2786: Blackhole loops are not detected and reported in GHCi In-Reply-To: <047.3bdf34422fea8ddbcf6903bcf24a5b4b@haskell.org> References: <047.3bdf34422fea8ddbcf6903bcf24a5b4b@haskell.org> Message-ID: <062.49f92c8f8d4883bf60bd5b4c714367c3@haskell.org> #2786: Blackhole loops are not detected and reported in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by lelf): * cc: me@?, hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 18:24:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 18:24:23 -0000 Subject: [GHC] #5916: runST isn't free In-Reply-To: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> References: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> Message-ID: <059.34497674651c9be1c255eafbfdd44a6c@haskell.org> #5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"e17a62c14b6a1fce681b06ebd0cc11223841f92f/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="e17a62c14b6a1fce681b06ebd0cc11223841f92f" Test that runST is not inlined prematurely This resulted form a discussion about #5916. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 18:24:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 18:24:31 -0000 Subject: [GHC] #5916: runST isn't free In-Reply-To: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> References: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> Message-ID: <059.c8655b51b90af550071ec00cc8e7a611@haskell.org> #5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Turns out I spoke too soon (and that the test suite really does not cover this): This code {{{ #!haskell main = let f () = runST $ do ref <- newSTRef 0 modifySTRef ref (+1) readSTRef ref in print (f () + f ()) }}} will be broken by my approach (output `3` instead of `2`), as there are no free variables that differing ? obvious, now that I see it. Too bad, was hoping to produce something usable today... at least I?ll add a possibly useful testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 18:53:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 18:53:22 -0000 Subject: [GHC] #8658: Document Proxy# Message-ID: <047.e0dfee19794c3ef30ae3c28b266d8a1d@haskell.org> #8658: Document Proxy# ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Commit [https://github.com/ghc/ghc/commit/17112084f87d7ccebf639068b85948190d52c6ba 17112084f87d7ccebf639068b85948190d52c6ba] introduced a new type `Proxy#` to `GHC.Prim`. However, I don't see any documentation for this type in the `GHC.Prim` haddock docs, or anywhere else. We should add this. A little poking around tells me that `compiler/prelude/primops.txt.pp` is the place to do it. But, I'm not familiar with that file's syntax, nor am I 100% familiar with `Proxy#`, so I don't think I'm the one to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 19:27:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 19:27:09 -0000 Subject: [GHC] #8656: Identical functions in Templeta Haskell In-Reply-To: <048.2ac272abe3740e215f6c78d1cb63e458@haskell.org> References: <048.2ac272abe3740e215f6c78d1cb63e458@haskell.org> Message-ID: <063.5d682cbb5270e8936fb09edb749a5c47@haskell.org> #8656: Identical functions in Templeta Haskell -------------------------------+------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by goldfire): My sense is that functions like `varE` (and even type synonyms like `ExpQ`) are present mainly to ease the implementation of the !DsMeta module. That module takes quotes (like `[| 1 + x |]`) and converts them into Core code (like `appE (appE (varE '+) (litE (integerL 1))) (varE 'x)`). So, even though `global` exists, it's really nice to have `varE` so that there is regularity in these monadic functions. (Each constructor, say, of `Exp` has a function counterpart defined in `Language.Haskell.TH.Lib`.) Whether or not it's useful to have `global` is another question. But, my thought is that it's best not to disrupt potential clients of that function. I agree that it's a little silly to have both of these functions, but it doesn't seem worth changing, to me. I'm also not sure how best to document this issue. My tendency would be toward closing this ticket as "wontfix", but I'll wait for someone to second my reasoning before doing so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 21:46:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 21:46:24 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.f4039631adfc0d93c4da7e3b603eab97@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by yoeight): Here's an implementation by introducing a new TH.Pred data constructor (let's say TypeT) as suggested by Richard [http://www.haskell.org/pipermail/ghc-devs/2014-January/003629.html here]: So, this is what I have in mind {{{#!haskell TypeT Type }}} By using the description's snippet, I got: {{{ VarI Tuple.foo (ForallT [PlainTV a_1627398569] [TypeP (AppT (AppT (TupleT 2) (AppT (ConT GHC.Show.Show) (VarT a_1627398569))) (AppT (ConT GHC.Read.Read) (VarT a_1627398569)))] (VarT a_1627398569)) Nothing (Fixity 9 InfixL) }}} What do you think ? Richard also suggested that we could make Pred a type synonym of TH.Type. Unfortunately, I have no idea how to express equality constraint only by using TH.Type -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 23:01:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 23:01:04 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.59b003706196532cd9a0ca6f6b5e845c@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): Do you mean `TypeP` in your example? For my suggestion about making `Pred` a synonym of `Type`, we would need to add something like `EqualityT` to represent the poly-kinded equality predicate. Although this isn't a Haskell type, strictly speaking, there is already precedent for that in the constructors `StarT` and `ConstraintT` (which aren't types either). I'm not sure which of these options (the `TypeP` or the synonym approach) is the better and would love to hear others' thoughts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 23:26:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 23:26:29 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.90f470cf9869b28f5249cb2d8081e105@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"af2ba9c81cf6a3223ccc74c5aa17de18138fd824/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="af2ba9c81cf6a3223ccc74c5aa17de18138fd824" Wrap `gmpz_tdiv_{q,r,qr}_ui` to optimize `quot`/`rem` This is useful as `quot`/`rem` are often used with small-int divisors, like when computing the digits of an `Integer`. This optimization reduces allocations in the following `nofib` benchmarks: Program Size Allocs Runtime Elapsed TotalMem ----------------------------------------------------------------- power +0.3% -0.8% -1.2% -1.2% +0.0% primetest +0.3% -3.9% 0.07 0.07 +0.0% rsa +0.3% -4.0% 0.02 0.02 +0.0% symalg +0.2% -1.4% 0.01 0.01 +0.0% This addresses #8647 Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 8 23:26:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Jan 2014 23:26:29 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.9aed480f088094320ab6e0073c211822@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"868b93beb1215a44f5f8251a397bba7fcc0815ad/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="868b93beb1215a44f5f8251a397bba7fcc0815ad" Manually float out `int2Integer# INT_MINBOUND` This avoids allocating this special value over and over again every time it's needed, and therefore this addresses #8647. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 03:02:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 03:02:02 -0000 Subject: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function In-Reply-To: <047.d854a286f40f24efedada1697ad637ee@haskell.org> References: <047.d854a286f40f24efedada1697ad637ee@haskell.org> Message-ID: <062.6ec4e4587071841f930d14d82e452aff@haskell.org> #1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: 4258 Blocking: | Related Tickets: 8326 -------------------------------------+------------------------------------- Changes (by nh2): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 04:40:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 04:40:16 -0000 Subject: [GHC] #8630: Kind inference fails to account for associated types In-Reply-To: <047.41bd20303828e55f4c52d905682e1177@haskell.org> References: <047.41bd20303828e55f4c52d905682e1177@haskell.org> Message-ID: <062.0199ce24a03ebf93e51506d8f01d2410@haskell.org> #8630: Kind inference fails to account for associated types --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: Fair enough. I took a look at what it would take to fix this, too, and came to much the same conclusion. I was rather hoping you might see some refactoring that would fix this bug ''and'' simplify gobs of other code in the process, as you sometimes do. When I have a chance, I might see if this behavior can be documented somewhere, as it did truly confuse me when I first hit it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 06:15:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 06:15:06 -0000 Subject: [GHC] #8658: Document Proxy# In-Reply-To: <047.e0dfee19794c3ef30ae3c28b266d8a1d@haskell.org> References: <047.e0dfee19794c3ef30ae3c28b266d8a1d@haskell.org> Message-ID: <062.d80c4f6b584729cb1b520b3b95e444ca@haskell.org> #8658: Document Proxy# -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Good catch. I'm validating a patch and checking it now... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 07:03:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 07:03:08 -0000 Subject: [GHC] #8658: Document Proxy# In-Reply-To: <047.e0dfee19794c3ef30ae3c28b266d8a1d@haskell.org> References: <047.e0dfee19794c3ef30ae3c28b266d8a1d@haskell.org> Message-ID: <062.c1e35ee0777286627035a26e01ae6f40@haskell.org> #8658: Document Proxy# -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"d4f0fcf368765ae4aa7ebe914bc2f254026694c8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d4f0fcf368765ae4aa7ebe914bc2f254026694c8" Document Proxy# (#8658) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 07:03:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 07:03:28 -0000 Subject: [GHC] #8658: Document Proxy# In-Reply-To: <047.e0dfee19794c3ef30ae3c28b266d8a1d@haskell.org> References: <047.e0dfee19794c3ef30ae3c28b266d8a1d@haskell.org> Message-ID: <062.bf52cab04652331ea8fac6c93dff9762@haskell.org> #8658: Document Proxy# -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Thanks Richard! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 08:06:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 08:06:30 -0000 Subject: [GHC] #8656: Identical functions in Templeta Haskell In-Reply-To: <048.2ac272abe3740e215f6c78d1cb63e458@haskell.org> References: <048.2ac272abe3740e215f6c78d1cb63e458@haskell.org> Message-ID: <063.590438e9a813375103c318aabfbf2595@haskell.org> #8656: Identical functions in Templeta Haskell -------------------------------+------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonpj): I'm inclined to deprecate `global`. I'll do that. S -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 08:23:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 08:23:41 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.11728db457ed88b7d7fbda82695e482d@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by simonpj): I rather agree with Richard: make `Pred` and `Type` into synonyms. That's what GHC does internally, and it works pretty well. However that would be a bit of a bump: people's programs would break. A possible half-way house would be to have {{{ data Pred = TypeP Type | ClassP Name [Type] | EqualP Type Type }}} and then deprecated `ClassP` and `EqualP` in favour of the equivalents in `Type`. Once that has settled down, making `Pred` into a synonym would still be a breaking change, but a very routine one to absorb. Or it might be better to do it all at once. I'm not sure, and would welcome opinions. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 08:37:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 08:37:44 -0000 Subject: [GHC] #5916: runST isn't free In-Reply-To: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> References: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> Message-ID: <059.daf4edb480888a75afbed48ff3a7458e@haskell.org> #5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I think the Right Thing here is to add a case to `CorePrep` that (in effect) inlines `runSTRep` on the spot. At that point there are no further transformations to worry about. Also it occurs to me that the C-- code for these two code fragments will be nearly identical {{{ (1) case st_rep s of (# _, r #) -> r (2) st_rep s }}} The latter will be a tail call; the former will push a return frame, call, and then simply return after that. So we could maybe code-gen (1) just like (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 08:52:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 08:52:12 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.9a4dcd5d743ee1b9da9e77029d65fa6a@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * cc: dcoutts (added) Comment: This isn't a blocker for the release, but Duncan should be looped in here if a cabal patch is needed. Duncan - any thoughts on this going upstream? Not immediate but input appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 08:53:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 08:53:08 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.720726f444ba15df51bfefe523e7ec5a@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Build System | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * cc: dcoutts (removed) * cc: duncan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 08:53:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 08:53:25 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.85ae8cd1ffdd80090e1fbd0c49f65349@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * owner: thoughtpolice => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 08:53:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 08:53:41 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.7736bc39ff78cd08d0782c67c20c0301@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 08:59:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 08:59:13 -0000 Subject: [GHC] #8656: Identical functions in Template Haskell (was: Identical functions in Templeta Haskell) In-Reply-To: <048.2ac272abe3740e215f6c78d1cb63e458@haskell.org> References: <048.2ac272abe3740e215f6c78d1cb63e458@haskell.org> Message-ID: <063.b2ad0629344a4c2a1594891df6dcaca1@haskell.org> #8656: Identical functions in Template Haskell -------------------------------+------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jstolarek): > I'm also not sure how best to document this issue. This could be documenting by explaining why we keep two identical functions, eg. `varE` for consistency and `global` to maintain API compatibility with existing code. Next person to see these two identical functions would not spend their time trying to figure out why do we have duplicate code :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 09:39:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 09:39:21 -0000 Subject: [GHC] #8622: Importing modules in .ghci file doesn't work In-Reply-To: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> References: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> Message-ID: <060.f56c4e3694093409810df8d5bc3433d3@haskell.org> #8622: Importing modules in .ghci file doesn't work ---------------------------------+---------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by simonmar): Replying to [comment:4 simonpj]: > > However, the [http://www.haskell.org/ghc/docs/latest/html/users_guide /interactive-evaluation.html user documentation] is not good on this point. Notably, it says (2.4.5.1) that "You cannot add a module to the scope if it is not loaded". But that's not true: you can also add (or `import`) any package module. > > Copying Simon M to check my statements here. If correct, I'll update the documentation. Yes, looks like it should say "if it is not loaded or a package module" or something. Maybe the negatives should be reversed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 13:39:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 13:39:26 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.eb7f7183afdfbf255104573e113a78b8@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by kgardas): Replying to [comment:13 carter]: > sounds reasonable. Will the arm 32 bit ghc calling convention make sense for AArch64? We may need to get a patch into llvm before having a distinct aarch64 abi. (and we should probably do some pretty thorough benchmarking before picking any such ABI) Not at all! aarch64 abi is completely different with completely different (or better nicely extended) register stack! So basically aarch64 is completely different beast than arm and I'm also doing it separately instead of extending current arm support. W.r.t. benchmarking, I've also had such discussion with David few year ago, but then Stephen comes with work done so no benchmarking was done. The point is to find some sweet-spot inbetween using callee-saved regs for STG regs pinning and between leaving them for LLVM business usage... Anyway, as I said, we're not there yet, although I already do have some code here. The problem is LLVM/AArch64 is not there yet as you can see from my bug report here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069248.html and that is just unregisterised build... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 14:23:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 14:23:35 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.c1c9a262202f7f42c4cd3a8a381cbfe0@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type | Version: None checker) | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by jgallag8): I am new to GHC, and I am interested in tackling this as my first task. Is there still interest in adding this feature? If so, I'll dive right in. Any pointers are appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 16:22:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 16:22:21 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.3b40d919ddc9c3bb904a0ea9b3e059ef@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type | Version: None checker) | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by goldfire): I'd like this, for one. As someone said previously, GHC should surely emit a warning when compiling an undefined function. And, I like the suggestion above of an informative `error` call instead of just using `undefined`. Thanks for rolling up your sleeves! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 18:03:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 18:03:40 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.6e990d5688f0db8cc4a8c3b7d41c347c@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): The first attempt was a bit naive; doing proper detection of surely converging expressions is a bit more involved. Some notes at the [wiki:NestedCPR#Convergesdetection] wiki page. Unfortunately it makes stuff that was safe before (such as removing variables from the environment of a strictness signature) not safe any more, so I expect it to take more work until the code is actually correct ? currently, simple tests work, but `ghc-stage2` diverges while eating up memory very fast. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 20:56:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 20:56:46 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.08357a02bd3cc7831edf9442f7b7e0c1@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): OK, so the near term is getting an unregisterized build working? thats still pretty awesome! please holler once you get that working! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 21:24:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 21:24:38 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.77610cfa95810ab92701e888ff966354@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): @karel, unregisterized builds use GCC specific C code, in which case you'll have to use GCC. GCC 4.8 and newer, when built with multi target support, seems to have aarch 64 support. clang/llvm wont work. cheers -Carter -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 21:42:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 21:42:04 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.2e73c158a428f652cbf3a02c545dd514@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by kgardas): Replying to [comment:16 carter]: > @karel, > unregisterized builds use GCC specific C code, in which case you'll have to use GCC. > > GCC 4.8 and newer, when built with multi target support, seems to have aarch 64 support. > > clang/llvm wont work. > > cheers > -Carter Carter, this is misunderstanding IMHO. I'm not dealing with unregisterised via C, but instead with unregisterised via LLVM build here. Please read the GHC/LLVM porting document I linked above for more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 22:15:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 22:15:53 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.f0e47badbdd9695e7269282529639e71@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): @karel, step 1 of that link says "make sure the unregisterized C build works" :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 9 23:01:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Jan 2014 23:01:40 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.0d68d9f145ec1cf98d6b442d2c397680@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by yoeight): Thanks for your advices ! I made Pred a type synonym of TH.Type. Impacted files sum up: {{{ dph-lifted-copy/Data/Array/Parallel/Lifted/TH/Repr.hs compiler/hsSyn/Convert.lhs compiler/typecheck/TcSplice.lhs Language/Haskell/TH.hs Language/Haskell/TH/Lib.hs Language/Haskell/TH/Ppr.hs Language/Haskell/TH/Syntax.hs }}} I have also made a test case based on description snippet Yorick -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 00:20:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 00:20:03 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.85b8fc687adc271c68d8de7d9d23a56e@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): I confirmed that @rpath is not used at this moment. Here is an example: {{{ % otool -L libHSsyb-0.4.1-ghc7.7.20140108.dylib libHSsyb-0.4.1-ghc7.7.20140108.dylib: /Users/kazu/work/ghc-mod/.cabal-sandbox/lib/x86_64-osx- ghc-7.7.20140108/syb-0.4.1/libHSsyb-0.4.1-ghc7.7.20140108.dylib (compatibility version 0.0.0, current version 0.0.0) }}} But note that this works without any problems. I applied darchon's patch, fully built GHC, and re-install cabal-install with the new GHC and Cabal. Unfortunately, this new cabal-install does now work well. For instance, syb becames: {{{ % otool -L libHSsyb-0.4.1-ghc7.7.20140108.dylib libHSsyb-0.4.1-ghc7.7.20140108.dylib: /private/var/folders/k0/548g5xg90jjfbrj5j09nvwv80000gq/T/syb-0.4.1-34816/syb-0.4.1/dist /dist-sandbox-a0e7ff68/build/libHSsyb-0.4.1-ghc7.7.20140108.dylib (compatibility version 0.0.0, current version 0.0.0) }}} So, libraries depending on syb cannot be installed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 01:22:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 01:22:16 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.1d70ebc88664bd99e154e343cac6c009@haskell.org> #8566: Given kind equalities are discarded -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I think that would be bad. For example, take the singleton for lists: {{{ data instance Sing (xs :: [k]) where SNil :: Sing '[] SCons :: Sing h -> Sing t -> Sing (h ': t) }}} The constructors expand to {{{ SNil :: forall (k :: BOX) (xs :: [k]). (xs ~ '[] k) => Sing [k] xs SCons :: forall (k :: BOX) (xs :: [k]). forall (h :: k) (t :: [k]). (xs ~ ((':) k h t)) => Sing k h -> Sing [k] t -> Sing [k] xs }}} (If you get suspicious of the `[k]` in the return type, it's because I didn't unfold the `data instance` piece of it. With that unfolded, the return type's indices are indeed variables.) These equalities mention kind variables, and yet I would be quite sad without them. Or did I miss something here? PS: I take back my claim about `k` being existential and `unA` being ill- typed. Simon is right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 02:58:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 02:58:06 -0000 Subject: [GHC] #8659: GHCi told me to tell you that it crashed Message-ID: <049.57e4ed0fa225e8edaa7ac3498047d812@haskell.org> #8659: GHCi told me to tell you that it crashed ------------------------------+------------------------------------- Reporter: ishkabible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+------------------------------------- I'm using an x86 build of GHCi version 7.4.2 on Windows 7 professional. I attempted to interpret the following code and GHC crashed and told me to report the issue. {{{ module ConstructorTypes where import Data.List (intercalate) import VarGenMonad data ConstructorSpec = Spec { parrentType :: ConstructorSpec, specName :: String, specArgs :: [Type] } deriving(Eq, Ord) data ConstructorTypeSpec = ConTypeSpec { conTypeName :: String, conSpecs :: [ConstructorSpec], numParams :: Int } data Pattern = Pat ConstructorSpec [Pattern] | Id String deriving(Eq, Ord) --this holds data Type = Poly Type | DeBruijnTypeVar Int | ConType ConstructorTypeSpec | Type :-> Type deriving(Eq, Ord, show) --define Eq and Ord to break infinte chain of type/spec/type/spec/... instance Eq ConstructorTypeSpec where t1 == t2 = conTypeName t1 == conTypeName t2 instance Ord ConstructorTypeSpec where t1 <= t2 = conTypeName t1 <= conTypeName t2 --create own show types to give a nice syntax and avoid infinite loops instance Show ConstructorSpec where show (Spec ty name args) = name ++ (concatMap ((' ':) . show) args) ++ " :: " ++ conTypeName ty instance Show ConstructorTypeSpec where show (ConTypeSpec name specs vars) = name ++ "=" ++ (concatMap (("\n\t" ++) . show) specs) genUniqueVars lst n = take n $ runVarGen lst gen where gen = do x <- drawVar return $ x : gen {-- toString env (Poly t) = do a <- drawVar --should advance to next varible b <- toString (a:env) t --any calls to drawVar in toString should advance it as well return $ "(forall " ++ a ++ ")" ++ b toString env (DeBruijn x) = do return $ env !! x --no changes are made here however toString env (ConType spec) = do names <- mapM_ (toString env) (typeVars spec) --each call to drawVar in each call toString should advance the internal state return $ conTypeName spec ++ intercalate " " names toString env (x :-> y) = do t1 <- toString env x t2 <- toString env y return $ "(" ++ t1 ++ ") -> " ++ t2 --} }}} "VarGenMonad" is the following code {{{ module VarGenMonad (VarGen, runVarGen, runVarGenWith, drawVar) where import Control.Monad --effectivlly a state monad of type State a [String] newtype VarGen a = VarGen { getFunc :: [String] -> (a, [String]) } --just gets the resulting value (this is what users will interface to) runVarGen vl vg = runVarGenWith showInt where showInt 0 = "" showInt x = show x --another function the user can interacte with runVarGenWith f vl vg = fst $ runState vg (makeVarListWith f vl) --gets the result from a var gen monad after telling it what varibles to use runState :: VarGen a -> [String] -> (a, [String]) runState vg vl = (getFunc vg) vl --creates an infinte list of unique varibles from a finite one makeVarListWith :: Integral a => (a -> String) -> [String] -> [String] makeVarListWith f lst = gen lst lst 0 where gen t [] c = gen t t (c + 1) gen t (x:xs) c = (x ++ f c) : gen t xs c --implements the monad operations in same fashion as a state monad instance Monad VarGen where return x = VarGen $ \s -> (x, s) cur >>= transform = VarGen func where func s = runState (transform v) nextList where (v, nextList) = runState cur s drawVar :: VarGen String drawVar = VarGen $ \(x:xs) -> (x, xs) }}} this worked before I added "show" (note that it is lowercase cuz I messed up) to the deriving cluase of my 'Type' type. After fixing it to make it an upper case S GHC promptly told me what else I had messed up in my code (that is, it worked correctly). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 03:04:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 03:04:17 -0000 Subject: [GHC] #8659: GHCi told me to tell you that it crashed In-Reply-To: <049.57e4ed0fa225e8edaa7ac3498047d812@haskell.org> References: <049.57e4ed0fa225e8edaa7ac3498047d812@haskell.org> Message-ID: <064.e8a4045b6f784377fee1199d8688caca@haskell.org> #8659: GHCi told me to tell you that it crashed -------------------------------------+--------------------------- Reporter: ishkabible | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.4.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: This is already fixed in GHC 7.6.3 and in HEAD. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 03:08:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 03:08:39 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.f7e7759dab87915f3ca2d25616ba498e@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): Do you have patches posted somewhere? And I'm surprised that you didn't have to modify `compiler/deSugar/DsMeta.lhs` to get this working -- that file handles translation of TH quotes, which should support the new kinds of predicates. Where is your test case? Have you run the testsuite? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 05:36:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 05:36:40 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.d3831a8b4c4acf6bce9bb250e619aeef@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): I will have a better look at Cabal... I really thought removing those lines would make sure that Cabal doesn't pass along an `install_name` to GHC; hence GHC would default to choosing an `@rpath`-based `install_name`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 07:31:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 07:31:09 -0000 Subject: [GHC] #8660: unexpected parsing error, "in" is treated as reserved word in type class constraints Message-ID: <045.97e758feda04d1a2d9f485506fadde43@haskell.org> #8660: unexpected parsing error, "in" is treated as reserved word in type class constraints -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I'm amidst writing a nice ffi binding to BLAS for ghc 7.6 and newer, and I hit an bizarre parser error when i had the follwoing type for a function transpose {{{ transposeMatrix :: (in ~ (Transpose out) , out ~ (Transpose in) ) => Matrix in elem -> Matrix out elem transposeMatrix (RowMajorMatrix x y stride arr)= (ColMajorMatrix x y stride arr) transposeMatrix (ColMajorMatrix x y stride arr) =(RowMajorMatrix x y stride arr) }}} {{{ src/Numerical/OpenBLAS/MatrixTypes.hs:83:21: parse error on input ?in? Failed, modules loaded: none. }}} i hit this error in GHC head I built this week AND with ghc 7.6 i'm pretty sure "in" shouldn't be a reserved word in types! If i rename "in" to "inor" the parser error goes away. if this is valid behavior, it'd be hepful to get a more precise parser error like "encountered reserved word "in", expected a variable" attaching the full module for your pleasure thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 08:29:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 08:29:04 -0000 Subject: [GHC] #8661: Segfault on System.Time during validate Message-ID: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> #8661: Segfault on System.Time during validate ----------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- I was running ?sh validate? today (commit d4f0fcf368765ae4aa7ebe914bc2f254026694c8) and I ended up with this error: {{{ cat ghc/ghc.wrapper >> inplace/bin /ghc-stage2 chmod +x inplace/bin /ghc-stage2 "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name old-time-1.1.0.2 -hide-all- packages -i -ilibraries/old-time/. -ilibraries/old-time/dist-install/build -ilibraries/old-time/dist-install/build/autogen -Ilibraries/old-time/dist- install/build -Ilibraries/old-time/dist-install/build/autogen -Ilibraries /old-time/include -optP-include -optPlibraries/old-time/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package old- locale-1.0.0.6 -Wall -XHaskell2010 -O2 -O -dcore-lint -fno-warn-amp -fno- warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries /old-time/dist-install/build -hidir libraries/old-time/dist-install/build -stubdir libraries/old-time/dist-install/build -dynamic-too -c libraries /old-time/dist-install/build/System/Time.hs -o libraries/old-time/dist- install/build/System/Time.o -dyno libraries/old-time/dist- install/build/System/Time.dyn_o gmake[1]: *** [libraries/old-time/dist-install/build/System/Time.o] Segmentation fault gmake[1]: *** Waiting for unfinished jobs.... Writing docs/users_guide/users_guide/ix01.html for index Writing docs/users_guide/users_guide/index.html for book(users-guide) cp mk/fptools.css docs/users_guide/users_guide/ gmake: *** [all] Error 2 }}} It built fine when I ran validate just the other day (at least after commit 32002b3dfdfd6a3c6a1a1eb52d8a257b42e17e51). 32-bit Linux Linux misaki 3.12.3-gentoo `#2` SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux Attaching full build log. This is a tree without any local changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 08:30:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 08:30:36 -0000 Subject: [GHC] #8661: Segfault on System.Time during validate In-Reply-To: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> References: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> Message-ID: <062.4db932b37d00f3d82a376d6d04111547@haskell.org> #8661: Segfault on System.Time during validate -------------------------------------+--------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by Fuuzetsu): Actually, I see that there's a 256KB limit on attachments. You can find the build log at http://fuuzetsu.co.uk/misc/cleanvalidate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 08:35:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 08:35:16 -0000 Subject: [GHC] #8661: Segfault on System.Time during validate In-Reply-To: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> References: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> Message-ID: <062.eabc2cae47e097573889180771f66576@haskell.org> #8661: Segfault on System.Time during validate -------------------------------------+--------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by Fuuzetsu): I'd like to add that the `ghc-stage2` binary produced segfaults the moment we try to compile anything with it, be it an invalid Haskell file (garbage string) or a valid program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 08:52:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 08:52:00 -0000 Subject: [GHC] #8651: 'Untouchable' error when using type function in class constraint in rank-2 type In-Reply-To: <047.64aa8af319a4eeeeafe09afd9844e657@haskell.org> References: <047.64aa8af319a4eeeeafe09afd9844e657@haskell.org> Message-ID: <062.44be12f7f597b57065e6670b6d338ff1@haskell.org> #8651: 'Untouchable' error when using type function in class constraint in rank-2 type --------------------------------------------+------------------------------ Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8644 | #7594 --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"5d2fb2ee94fea4cf62ba767eb1555e42f4f21f46/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5d2fb2ee94fea4cf62ba767eb1555e42f4f21f46" Further refine the test for 'given' equalities Trac #8651 revealed that my previous fix (itself in response to #8644) wasn't quite right. The plan, using the CtOrigin to identify constraints arising from flattening, is described in TcSimplify, Note [When does an implication have given equalities?] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 08:52:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 08:52:00 -0000 Subject: [GHC] #8644: 'Untouchable' error with constraint variable in rank-2 type In-Reply-To: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> References: <047.3b0cdf413c3f987fdab206c0248d0b2b@haskell.org> Message-ID: <062.625fff967bf0186ba19f1a121344a60b@haskell.org> #8644: 'Untouchable' error with constraint variable in rank-2 type -------------------------------------------------+------------------------- Reporter: sbarclay | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler (Type checker) | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple typecheck/should_compile/T8644 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5d2fb2ee94fea4cf62ba767eb1555e42f4f21f46/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5d2fb2ee94fea4cf62ba767eb1555e42f4f21f46" Further refine the test for 'given' equalities Trac #8651 revealed that my previous fix (itself in response to #8644) wasn't quite right. The plan, using the CtOrigin to identify constraints arising from flattening, is described in TcSimplify, Note [When does an implication have given equalities?] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 08:52:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 08:52:02 -0000 Subject: [GHC] #8622: Importing modules in .ghci file doesn't work In-Reply-To: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> References: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> Message-ID: <060.9c9d54199ab5e885b6449ac97127d975@haskell.org> #8622: Importing modules in .ghci file doesn't work ---------------------------------+---------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0ec530202369fef2fecc7446027a65b4a345f0a9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0ec530202369fef2fecc7446027a65b4a345f0a9" Improve documentation of :module etc (Trac #8622) I did quite a bit of restructuring, as well as adding the note specifically referred to in #8622 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 08:52:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 08:52:02 -0000 Subject: [GHC] #8278: Improve error message when the same type is imported from two different library versions In-Reply-To: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> References: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> Message-ID: <059.dbce868e6f3f764198d4fa7bfe8f2e6c@haskell.org> #8278: Improve error message when the same type is imported from two different library versions -------------------------------------------------+------------------------- Reporter: Yuras | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple typecheck/should_fail/tcfail182 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"322b48b92b93e1250b360d21873fa9f31c142403/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="322b48b92b93e1250b360d21873fa9f31c142403" Further improve the "same-occurrence" error messages (Trac #8278) Sometimes we actually have a good SrcSpan for the type constructor and reporting that is better than just reporting which module it was defined on }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 08:52:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 08:52:03 -0000 Subject: [GHC] #8649: Disambiguate Repeated Identifiers for data types in error messages In-Reply-To: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> References: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> Message-ID: <064.35cfda06cf0923e99b5396b4efef8fda@haskell.org> #8649: Disambiguate Repeated Identifiers for data types in error messages -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"73c08ab10e4077e18e459a1325996bff110360c3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="73c08ab10e4077e18e459a1325996bff110360c3" Re-work the naming story for the GHCi prompt (Trac #8649) The basic idea here is simple, and described in Note [The interactive package] in HscTypes, which starts thus: Note [The interactive package] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Type and class declarations at the command prompt are treated as if they were defined in modules interactive:Ghci1 interactive:Ghci2 ...etc... with each bunch of declarations using a new module, all sharing a common package 'interactive' (see Module.interactivePackageId, and PrelNames.mkInteractiveModule). This scheme deals well with shadowing. For example: ghci> data T = A ghci> data T = B ghci> :i A data Ghci1.T = A -- Defined at :2:10 Here we must display info about constructor A, but its type T has been shadowed by the second declaration. But it has a respectable qualified name (Ghci1.T), and its source location says where it was defined. So the main invariant continues to hold, that in any session an original name M.T only refers to oe unique thing. (In a previous iteration both the T's above were called :Interactive.T, albeit with different uniques, which gave rise to all sorts of trouble.) This scheme deals nicely with the original problem. It allows us to eliminate a couple of grotseque hacks - Note [Outputable Orig RdrName] in HscTypes - Note [interactive name cache] in IfaceEnv (both these comments have gone, because the hacks they describe are no longer necessary). I was also able to simplify Outputable.QueryQualifyName, so that it takes a Module/OccName as args rather than a Name. However, matters are never simple, and this change took me an unreasonably long time to get right. There are some details in Note [The interactive package] in HscTypes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 08:53:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 08:53:01 -0000 Subject: [GHC] #5498: Generalized newtype deriving allows creating of instances I can't create by hand In-Reply-To: <045.07b11c8f532229ab6848cf0b72e86f9b@haskell.org> References: <045.07b11c8f532229ab6848cf0b72e86f9b@haskell.org> Message-ID: <060.a498417b997ccecd6b366abd32618352@haskell.org> #5498: Generalized newtype deriving allows creating of instances I can't create by hand -----------------------------------------------+--------------------------- Reporter: dterei | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: deriving/should_fail/T5498 | Difficulty: Unknown Blocking: | Blocked By: 1496 | Related Tickets: -----------------------------------------------+--------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1285af76c32c84332835d5d430146403bf610796/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="1285af76c32c84332835d5d430146403bf610796" Test Trac #5498 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 08:53:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 08:53:01 -0000 Subject: [GHC] #8649: Disambiguate Repeated Identifiers for data types in error messages In-Reply-To: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> References: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> Message-ID: <064.7aaf3faac7b015c3518a94e4671665bf@haskell.org> #8649: Disambiguate Repeated Identifiers for data types in error messages -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"5e8e8e6e62c5826133c053cd78bb35e9b4aaa05b/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="5e8e8e6e62c5826133c053cd78bb35e9b4aaa05b" Changes in error messages when fixing Trac #8649 Mostly improvements, happily }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 09:08:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 09:08:19 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.cb96e9f56dff3350203162095483eac1@haskell.org> #8566: Given kind equalities are discarded -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Aha. But there is a real difference between the two: {{{ MkT :: forall (u:*). forall (k:BOX), (b:k). (u ~ Proxy k b) => Proxy k b -> T u SNil :: forall (k:BOX) (xs:[k]). (xs ~ '[] k) => Sing22 k xs }}} (I've used `Sing22` for the data type for `Sing (xs:[k])`.) In `SNil` the `k` is univerally quantified over the whole thing. In `MkT` the `k` is existentially quantified, ''and'' involved in an equality constraint. So I rephrase my proposal: '''reject any data constructor with an existentially quantified kind variable that is mentioned in an equality constraint'''. Of course "mentioned in an equality constraint" is itself not too obvious (think superclasses and constraint kinds). But is the direction of travel right? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 09:15:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 09:15:41 -0000 Subject: [GHC] #8660: unexpected parsing error, "in" is treated as reserved word in type class constraints In-Reply-To: <045.97e758feda04d1a2d9f485506fadde43@haskell.org> References: <045.97e758feda04d1a2d9f485506fadde43@haskell.org> Message-ID: <060.b2915a6b5a6e33b7a5c08f9bdce216fb@haskell.org> #8660: unexpected parsing error, "in" is treated as reserved word in type class constraints --------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Well, for better or worse, `in` is a keyword: see the [http://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2 language definition]. Some words like `hiding` have special significance only in particular places, but `in` isn't one of them. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 09:23:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 09:23:07 -0000 Subject: [GHC] #8649: Disambiguate Repeated Identifiers for data types in error messages In-Reply-To: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> References: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> Message-ID: <064.1e7071ac0c5d202ae61baefaee6dbead@haskell.org> #8649: Disambiguate Repeated Identifiers for data types in error messages -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"d63acc8fd99553b2fcca02b58519877827b913ac/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="d63acc8fd99553b2fcca02b58519877827b913ac" Test Trac #8649 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 09:23:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 09:23:29 -0000 Subject: [GHC] #8649: Disambiguate Repeated Identifiers for data types in error messages In-Reply-To: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> References: <049.6bf3d73425bf24e65a9a228212868f45@haskell.org> Message-ID: <064.31493587c0028fef2765ae59a24661b1@haskell.org> #8649: Disambiguate Repeated Identifiers for data types in error messages ---------------------------------------+----------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8649 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghci/scripts/T8649 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 09:28:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 09:28:21 -0000 Subject: [GHC] #8651: 'Untouchable' error when using type function in class constraint in rank-2 type In-Reply-To: <047.64aa8af319a4eeeeafe09afd9844e657@haskell.org> References: <047.64aa8af319a4eeeeafe09afd9844e657@haskell.org> Message-ID: <062.f9e0ab40c539ca083a2450da11018e7d@haskell.org> #8651: 'Untouchable' error when using type function in class constraint in rank-2 type --------------------------------------------+------------------------------ Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8644 | #7594 --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"b662393ef802b80e211f494f7b22aa1964faaed5/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="b662393ef802b80e211f494f7b22aa1964faaed5" Test Trac #8651 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 09:29:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 09:29:04 -0000 Subject: [GHC] #8651: 'Untouchable' error when using type function in class constraint in rank-2 type In-Reply-To: <047.64aa8af319a4eeeeafe09afd9844e657@haskell.org> References: <047.64aa8af319a4eeeeafe09afd9844e657@haskell.org> Message-ID: <062.80fccc4fec67d22eb6d8d48e0fda4876@haskell.org> #8651: 'Untouchable' error when using type function in class constraint in rank-2 type -------------------------------------------------+------------------------- Reporter: sbarclay | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler (Type checker) | Milestone: Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple indexed_types/should_compile/T8651 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #8644 | #7594 -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed_types/should_compile/T8651 * resolution: => fixed Comment: Very excellent catch, thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 09:35:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 09:35:19 -0000 Subject: [GHC] #8656: Identical functions in Template Haskell In-Reply-To: <048.2ac272abe3740e215f6c78d1cb63e458@haskell.org> References: <048.2ac272abe3740e215f6c78d1cb63e458@haskell.org> Message-ID: <063.7376ef2be1f9fa875473b13d43ce4a43@haskell.org> #8656: Identical functions in Template Haskell -------------------------------+------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK I've deprecated `global`: {{{ commit 6b485668ba22d4d78664866100a8ef2daf62ff89 Author: Simon Peyton Jones Date: Thu Jan 9 18:01:06 2014 +0000 Deprecate TH.global (Trac #8656) >--------------------------------------------------------------- 6b485668ba22d4d78664866100a8ef2daf62ff89 Language/Haskell/TH/Lib.hs | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Language/Haskell/TH/Lib.hs b/Language/Haskell/TH/Lib.hs index 2dfef30..b7a88d6 100644 --- a/Language/Haskell/TH/Lib.hs +++ b/Language/Haskell/TH/Lib.hs @@ -200,6 +200,8 @@ dyn :: String -> ExpQ dyn s = return (VarE (mkName s)) global :: Name -> ExpQ +{-# DEPRECATED global "Use varE instead" #-} +-- Trac #8656; I have no idea why this function is duplicated global s = return (VarE s) varE :: Name -> ExpQ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 10:05:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 10:05:05 -0000 Subject: [GHC] #8661: Segfault on System.Time during validate In-Reply-To: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> References: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> Message-ID: <062.63d3e24e82ee6576a73040335a0c31bf@haskell.org> #8661: Segfault on System.Time during validate -------------------------------------+--------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"a3878d172b358b896b3c8302e58199958479d8e5/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="a3878d172b358b896b3c8302e58199958479d8e5" Temporary disable `mpz_gmpz_tdiv_qr_ui` to workaround #8661 I still need to investigated, but for some reason not yet obvious to me, commit [af2ba9c8/integer-gmp] (re #8647) seems to have triggered #8661 on linux/32 This commit disables the use of the `quotRemIntegerWord#` primop on 32bit (which seems to trigger the issue). Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 10:05:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 10:05:06 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.2c9f43a7b0bbf66432640d65cab4cbb9@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"a3878d172b358b896b3c8302e58199958479d8e5/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="a3878d172b358b896b3c8302e58199958479d8e5" Temporary disable `mpz_gmpz_tdiv_qr_ui` to workaround #8661 I still need to investigated, but for some reason not yet obvious to me, commit [af2ba9c8/integer-gmp] (re #8647) seems to have triggered #8661 on linux/32 This commit disables the use of the `quotRemIntegerWord#` primop on 32bit (which seems to trigger the issue). Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 13:30:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 13:30:49 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.e0fa061282bd306cc8e75ed3fabf92b5@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type | Version: None checker) | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): I suggest * A language extension flag `-XUndefinedFunctions` or something * In the renamer you'll have to arrange to create a binder for a signature that lacks a corresponding binding; and give an warning (rather than an error) for such signatures. * I suggest that you actually add the definition `f = error "Missing definition for f"` (or whatever) in the desugarer. GHC generally tries NOT to mess with the source code until desugaring, so that you can always show exactly what the user wrote. Happy to discuss when you get a bit further Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 13:37:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 13:37:24 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.587b8f19c6de2305e5eecec8e6ceecf2@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type | Version: None checker) | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonmar): For what it's worth, this is part of #5791 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 13:50:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 13:50:02 -0000 Subject: [GHC] #5791: Defer other kinds of errors until runtime, not just type errors In-Reply-To: <047.a223fe09070117a89d89b35e963562e7@haskell.org> References: <047.a223fe09070117a89d89b35e963562e7@haskell.org> Message-ID: <062.3eb2691eab39cb3ea681976062a439c6@haskell.org> #5791: Defer other kinds of errors until runtime, not just type errors -------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5778 #393 -------------------------------------+------------------------------------ Changes (by nomeata): * related: 5778 => #5778 #393 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 14:27:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 14:27:35 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.a50afdd91a5b31bdb9b639953fc8a295@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: sweirich@? (added) Comment: We really want explicit type application here (#4466, #5296). The point is that we want to say "instantiate `coerce` at these particular types", which happen in this case to be polymorphic. (There is a good reason to be suspicious about filling in unification variables with polytypes, but explicit type application would mean that didn't happen.) Stephanie has a student working on this, I believe. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 14:31:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 14:31:00 -0000 Subject: [GHC] #8662: GHC does not inline cheap inner loop when used in two places Message-ID: <042.69b3bccc171bc071ffddab8e8b0c335c@haskell.org> #8662: GHC does not inline cheap inner loop when used in two places ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- When I made a Criterion benchmark of Neil Michell's "Tight Inner Loop" blog post (http://neilmitchell.blogspot.co.uk/2014/01/optimising-haskell- for-tight-inner-loop.html), I noticed that GHC 7.6.3 will not inline the performance-critical function when it's called from two different places (inside the same module). {{{ break0_2pleaseinline :: (Char -> Bool) -> ByteString0 -> (ByteString, ByteString0) break0_2pleaseinline f (BS0 bs) = (BS.unsafeTake i bs, BS0 $ BS.unsafeDrop i bs) where i = Internal.inlinePerformIO $ BS.unsafeUseAsCString bs $ \ptr -> do let start = castPtr ptr :: Ptr Word8 let end = go start return $! Ptr end `minusPtr` start go s@(Ptr a) | c == '\0' || f c = a | otherwise = go $ inc s where c = chr s versionInl1 :: ByteString0 -> (ByteString, ByteString0) versionInl1 str = break0_2pleaseinline test str where test x = x <= '$' && (x == ' ' || x == '\r' || x == '\n' || x == '$') versionInl2 :: ByteString0 -> (ByteString, ByteString0) versionInl2 str = break0_2pleaseinline test str where test x = x <= '$' && (x == ' ' || x == '\r' || x == '\n' || x == '$') }}} Full code here: https://github.com/nh2/inner-loop- benchmarks/blob/6715d1e9946d6b5e6d9bb53203982ed3d2ed32ff/Bench.hs#L166. {{{break0_2pleaseinline}}} does not get inlined, which makes {{{versionInl1}}} and {{{versionInl2}}} over 4 times slower than when inlined. The inlining doens't happen, not even with {{{-O2}}} and {{{-O3}}}, only an {{{INLINE}}} pragma will move GHC to do it. If I was a compiler, I would so inline that function! I am surprised that GHC doesn't decide to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 14:39:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 14:39:40 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.7774d8edd84b25bc9e9ed1ec7a9221dd@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type | Version: None checker) | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by jgallag8): Simonpj - Thanks very much for the advice. If I need more pointers, I'll let you know once I have become a little more familiar with the code base. Simonmar - Do you suggest the two be handled together? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 16:38:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 16:38:33 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.2880d3c6c836d1850f85dca8f9579976@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by kgardas): @carter: but -fvia-C is no longer supported, at least, https://ghc.haskell.org/trac/ghc/wiki/Building/Porting suggests that. So LLVM is the only way for AArch64 as we do not have NCG ready for this platform... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 17:15:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 17:15:59 -0000 Subject: [GHC] #8622: Importing modules in .ghci file doesn't work In-Reply-To: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> References: <045.da51299b2472d1ff8f4ee8cce5f9a2e8@haskell.org> Message-ID: <060.4af4e63441fb011ef0bad5b74e8f57ee@haskell.org> #8622: Importing modules in .ghci file doesn't work ---------------------------------+---------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by m4dc4p): I'm glad my ticket resulted in such an improvement to the documentation - thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 17:48:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 17:48:07 -0000 Subject: [GHC] #8661: Segfault on System.Time during validate In-Reply-To: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> References: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> Message-ID: <062.a90c2fabe0f5a1ff4e316983321508d6@haskell.org> #8661: Segfault on System.Time during validate -------------------------------------+--------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by nomeata): I still observe a weridness, ghc spins for a long time trying to compile System.Time. According to `-v`, it is somewhere in the desugarer ? is that possibly related to this ticket or did I hit a different, possibly local, issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 18:08:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 18:08:06 -0000 Subject: [GHC] #8661: Segfault on System.Time during validate In-Reply-To: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> References: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> Message-ID: <062.a3acfbf7a844100092e51fb81f7c0fdb@haskell.org> #8661: Segfault on System.Time during validate -------------------------------------+--------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by nomeata): Nevermind, it is only on my branch... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 18:16:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 18:16:58 -0000 Subject: [GHC] #8616: "Internal error" with ScopedTypeVariables and kind variables In-Reply-To: <047.f65784d6e37be57e3df5d424a2fe4ddd@haskell.org> References: <047.f65784d6e37be57e3df5d424a2fe4ddd@haskell.org> Message-ID: <062.0f0ac6490d7fd511c4e017d203a4e77a@haskell.org> #8616: "Internal error" with ScopedTypeVariables and kind variables -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"17a3dacba03f7a800444c135e93ce1b81a89e158/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="17a3dacba03f7a800444c135e93ce1b81a89e158" Bring kind variables into the type-checker's scope as well as type variables Fixes Trac #8616 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 18:53:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 18:53:44 -0000 Subject: [GHC] #8660: unexpected parsing error, "in" is treated as reserved word in type class constraints In-Reply-To: <045.97e758feda04d1a2d9f485506fadde43@haskell.org> References: <045.97e758feda04d1a2d9f485506fadde43@haskell.org> Message-ID: <060.c3ee38485c98149f5df4e3062ee2a625@haskell.org> #8660: unexpected parsing error, "in" is treated as reserved word in type class constraints --------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by carter): agree, I'm moreso suggesting that the error message should be more like "error, unexpected reserved word "in" at $FILE:LOCATION" rather than "there was a syntax error here". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 20:07:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 20:07:05 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.4b6318a78a97b2998451321c4fd3f256@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Yes, absolutely, explicit type application would make all of this much easier. But, I believe we can still fix this bug without it, once we have some design decisions about the questions I posed originally. As for question 1: I think it's safe to turn on !ImpredicativeTypes over the code produced by GND. This would make using GND easier, and I don't want to bother users with this technicality. As for question 2: In general, I'm a little worried about error messages that mention `coerce` yet refer to code that patently does ''not'' mention `coerce`. If we can't get rid of the `coerce`, could we add some extra context describing the use of GND and perhaps suggesting `-ddump-deriv`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 20:14:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 20:14:25 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.4a0d3121a1ace0d020d2765abd1d3d60@haskell.org> #8566: Given kind equalities are discarded -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I can't find a case where I want an existentially quantified kind variable in an equality constraint, so I think that proposal is viable. ''But'', I think your comment that "'mentioned in an equality constraint' is not obvious" is an understatement. What if a context uses an open type family? Then, we can't know whether or not the type family will expand out to an equality constraint. We could forbid those, too, I suppose, but I don't like where this is going. I might prefer emitting a (suppressable) warning in this case, saying that the user is pushing the type system beyond its limits, really, and to expect the unexpected. Or, we could go the other way and allow such declarations only when the user specifies `-XAllowWonkyExistentialKinds` or similar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 20:18:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 20:18:12 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.18de57c75925d4667a77ee68d7d3664f@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+--------------------------- Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623 Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): no, -fvia-C still works, i know (because i broke it accidentaly early fall) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 21:12:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 21:12:37 -0000 Subject: [GHC] #8630: Kind inference fails to account for associated types In-Reply-To: <047.41bd20303828e55f4c52d905682e1177@haskell.org> References: <047.41bd20303828e55f4c52d905682e1177@haskell.org> Message-ID: <062.16dc5094e4b86baa7de801813e314339@haskell.org> #8630: Kind inference fails to account for associated types --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Richard Eisenberg ): In [changeset:"0369c9745e2ce66f4c2d817a3aa9f2487395e0c7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0369c9745e2ce66f4c2d817a3aa9f2487395e0c7" Clarify issue in #8630 in users' guide. We do *not* propagate kind information from an instance declaration's members back into the instance head. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 21:12:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 21:12:37 -0000 Subject: [GHC] #8599: Deriving in associated data families ignores instance's constraints In-Reply-To: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> References: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> Message-ID: <062.89c2927b0d2401223654dcb8c9247649@haskell.org> #8599: Deriving in associated data families ignores instance's constraints -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"566ba6fa10ade0af159a7b86f4df706cbd6b4163/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="566ba6fa10ade0af159a7b86f4df706cbd6b4163" Fix #8599. This change is just some documentation around ignoring the context of an enclosing instance when processing `deriving` clauses of an associated data instance. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 21:13:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 21:13:37 -0000 Subject: [GHC] #8599: Deriving in associated data families ignores instance's constraints In-Reply-To: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> References: <047.15721e4f15b895eba1da55bf5a43686a@haskell.org> Message-ID: <062.fd9821021d907fe3ac2c9d5aea5a8804@haskell.org> #8599: Deriving in associated data families ignores instance's constraints -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 10 22:25:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Jan 2014 22:25:37 -0000 Subject: [GHC] #8663: Fix up Haddock mark-up Message-ID: <047.a5cef90a0af192908b486d98b7c3c24e@haskell.org> #8663: Fix up Haddock mark-up ------------------------------------+-------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- New Haddock changes will mean that any previously failing Haddock parses (which resulted in no documentation) will now be parsed. This means that the resulting documentation might not look too great. These need to be human-checked and fixed up if needed. Here are the failures from recent validate run: {{{ 14923:doc comment parse failed: block decorated with fact 14924- @ end dg.tex 14925-Warning: Compiler.Hoopl.Dataflow: Instances of type and data families and equations of closed type families are not yet supported.Instances of the following families will be filtered out: 14926- Fact 14927- 30% ( 10 / 33) in 'Compiler.Hoopl.Dataflow' }}} {{{ 17735:doc comment parse failed: plusUFM_CD f m1 d1 m2 d2 17736- merges the maps using `f` as the combinding function and d1 resp. d2 as 17737- the default value if there is no entry in m1 reps. m2. The domain is the union 17738- of the domains of m1 m2. 17739- Representative example: 17740- > plusUFM_CD f {A: 1, B: 2} 23 {B: 3, C: 4} 42 17741- > == {A: f 1 42, B: f 2 3, C: f 23 4 } 17742- 4% ( 2 / 49) in 'UniqFM' }}} {{{ 17790:doc comment parse failed: If @co :: T ts ~ rep_ty@ then: 17791- 17792- > instNewTyCon_maybe T ts = Just (rep_ty, co) 17793- Checks for a newtype, and for being saturated 17794- 32% ( 38 /117) in 'Coercion' }}} {{{ 17813-haddock module header parse failed: Cannot parse header documentation paragraphs 17814- 75% ( 3 / 4) in 'Llvm.MetaData' }}} {{{ 18100:doc comment parse failed: @argTyFold@ implements a generalised and safer variant of the @arg@ 18101- function from Figure 3 in . @arg@ 18102- is conceptually equivalent to: 18103- 18104- > arg t = case t of 18105- > _ | isTyVar t -> if (t == argVar) then Par1 else Par0 t 18106- > App f [t'] | 18107- representable1 f && 18108- t' == argVar -> Rec1 f 18109- > App f [t'] | 18110- representable1 f && 18111- t' has tyvars -> f :.: (arg t') 18112- > _ -> Rec0 t 18113- 18114- where @argVar@ is the last type variable in the data type declaration we are 18115- finding the representation for. 18116- 18117- @argTyFold@ is more general than @arg@ because it uses 'ArgTyAlg' to 18118- abstract out the concrete invocations of @Par0@, @Rec0@, @Par1@, @Rec1@, and 18119- @:.:@. 18120- 18121- @argTyFold@ is safer than @arg@ because @arg@ would lead to a GHC panic for 18122- some data types. The problematic case is when @t@ is an application of a 18123- non-representable type @f@ to @argVar@: @App f [argVar]@ is caught by the 18124- @_@ pattern, and ends up represented as @Rec0 t at . This type occurs /free/ in 18125- the RHS of the eventual @Rep1@ instance, which is therefore ill- formed. Some 18126- representable1 checks have been relaxed, and others were moved to 18127- @canDoGenerics1 at . 18128- 0% ( 0 / 8) in 'TcGenGenerics' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 00:05:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 00:05:54 -0000 Subject: [GHC] #8661: Segfault on System.Time during validate In-Reply-To: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> References: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> Message-ID: <062.b14fb28fe475a0d441774866e9973565@haskell.org> #8661: Segfault on System.Time during validate -------------------------------------+--------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"13b4d0cdd18471de33ba89bda11a4b238507b7c7/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="13b4d0cdd18471de33ba89bda11a4b238507b7c7" Drop redundant formal parameter from TAKE1_UL1_RET2 This fixes the actual cause for #8661, i.e. a mismatch between the actual arity of the Cmm implementation and the arity declared in the foreign import statement. This also reverts [a3878d17/integer-gmp] as the workaround isn't needed anymore. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 00:13:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 00:13:44 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.028b68064991f3019531b5be0d9ff62e@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I thought I had got rid of `coerce` in error messages when doing GND (#8567)... I?ll have to look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 00:14:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 00:14:43 -0000 Subject: [GHC] #8661: Segfault on System.Time during validate In-Reply-To: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> References: <047.21f67e1aa51470b1a7daf3df9d911e99@haskell.org> Message-ID: <062.a7bab6fe680c05de0066d93e6bc3641f@haskell.org> #8661: Segfault on System.Time during validate -------------------------------------+--------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+--------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 00:39:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 00:39:30 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.d5915073e764a39f1a05e3105dec4cc0@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): It should have been [95ba5d81/ghc]: We check at deriving time that the `Coercible` instances are solvable, and report an appropriate error message; any time that there is an error message mentioning `coercible` (or deriv-generated code in general), that is a bug. So unless turning on `ImpredicativeTypes` for deriv?ed code solve the problem, we need to check for this already at deriving phase, and report an error. What would that error say? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 12:52:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 12:52:57 -0000 Subject: [GHC] #8664: libffi does not recognize AArch64 (ARM64) Message-ID: <046.f6fd599894b770d8f463eddb4be500e6@haskell.org> #8664: libffi does not recognize AArch64 (ARM64) -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Hello, bundled libffi-3.0.11's configure does not recognize aarch64/arm64 platform. This is easily solvable by replacing it with newer release. I tested 3.0.13 and it went well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 12:54:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 12:54:00 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.c9aa0599d7a1fbe9c7f5497952337a3c@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623, 8664 Blocking: | Related Tickets: --------------------------------------------+------------------------------ Changes (by kgardas): * blockedby: 7623 => 7623, 8664 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 13:35:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 13:35:50 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.fb3792aa3ba282943e7013c558665f8a@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by yoeight): Surprisingly, I didn't have to modify `DsMeta.lhs` but I had to change a couple of test files that I've forgot in my sum up (respectively `T8625.stdout` and `TH_genExLib.hs`) I did run the testsuite and everything is working properly Patches can be found [https://gist.github.com/YoEight/8370987 here]. Unfortunately, there were trailing whitespaces in some files -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 13:43:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 13:43:49 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.dc269675de2b3cbb5d88a8e119a22266@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623, 8664 Blocking: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kgardas): Good! So this LLVM bug above shows only on PrimoptWrappers and I've been able to compile this file without -fllvm as Carter points out above. So here is bindist's HelloWorld running on AArch64/ARM64 platform: {{{ root at localhost:~# ./HelloWorld Hello world!root at localhost:~# file HelloWorld HelloWorld: ELF 64-bit LSB executable, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.7.0, BuildID[sha1]=0x5301662c82ccd3fe7c3f1486ac10d0f13b2f54c9, not stripped root at localhost:~# uname -m aarch64 root at localhost:~# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 17:25:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 17:25:38 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.6ae8960c16aa7e1d0a5422ac88490a59@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): This looks nice -- I can easily believe it works. Here is some feedback I have on the code: * I would want to see this handle `IrredPred` predicates, as well as tuples. That way, synonyms built with !ConstraintKinds would be fully supported by TH. I don't think this should be too much work beyond what you've already done. * I still think a change to !DsMeta is warranted. For example, I would imagine code like `[t| (Show a, (Read a, Num a)) => a -> a |]` would fail to compile, even though TH would now be able to represent such a predicate. * The functions `classP` and `equalP` in the `Lib` module are meant to echo the constructors of `Pred`. I would say that, now that `Pred` is a synonym, `classP` and `equalP` should be removed. (It took me a while to understand why all those functions are there in `Lib` -- the answer is that !DsMeta is ''much'' easier to write with those functions there.) Leaving `classP` and `equalP` doesn't cause anyone any real harm, but it would just be a small wart on the design that could easily be eliminated. * Along similar lines, you will probably find that you need an `equalityT` function in `Lib` when updating !DsMeta. * It looks like you left the old `Pred` commented-out in `Syntax`. * While it is probably too late now (and I don't think worth going back to fix), it's best to do whitespace changes in separate commits from substantive changes. Perhaps before editing a new file, removing the trailing whitespace, make a commit, and then go back and to the real changes. You can always then rebase at the end of your session to lump together all the whitespace commits. Continued thanks for working on this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 19:36:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 19:36:05 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.17a2efbf357cf604d0bb2fdc4c72ca2e@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type | Version: None checker) | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonmar): I think that this is another kind of "deferred error", in the same sense of `-fdefer-type-errors`, and there are lots of other kinds of errors that we want to defer (e.g. out-of-scope identifiers). So all I'm suggesting is that we should bear this in mind, and perhaps use a consistent naming convention for flags, e.g. this particular one could be `-fdefer-missing- decl-errors`, which would eventually become part of `-fdefer-renamer- errors`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 20:52:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 20:52:34 -0000 Subject: [GHC] #5916: runST isn't free In-Reply-To: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> References: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> Message-ID: <059.7e03c1c3bb6bf2ea793b6d5ef6e6ca26@haskell.org> #5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Replying to [comment:15 simonpj]: > Also it occurs to me that the C-- code for these two code fragments will be nearly identical > {{{ > (1) case st_rep s of (# _, r #) -> r > (2) st_rep s > }}} > The latter will be a tail call; the former will push a return frame, call, and then simply return after that. So we could maybe code-gen (1) just like (2). Not exactly: (1) evaluates `r`, but (2) doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 11 21:27:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Jan 2014 21:27:54 -0000 Subject: [GHC] #8623: Strange slowness when using async library with FFI callbacks In-Reply-To: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> References: <050.b698b67eedde827d2c2feb4d7fb38092@haskell.org> Message-ID: <065.38aac621b1ace396f93531894c74f517@haskell.org> #8623: Strange slowness when using async library with FFI callbacks --------------------------------------------+------------------------------ Reporter: JohnWiegley | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): So I understand why this happens, but I don't have a good idea for what to do about it yet. The problem is that each call into the RTS from the C function is very short, and when it is complete. the next call creates a new thread that goes to the back of the run queue. The main thread then gets a full time slice before the new thread gets to run. You can see the effect with `+RTS -C0.1` which halves the time slice length and halves the time to run the program. The new thread goes to the back of the queue to avoid possible starvation of other threads in the queue. Somehow we want to make the new thread inherit the rest of the timeslice from the previous thread, but I need to think some more about how we can do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:37 -0000 Subject: [GHC] #441: GHCi doesn't run computations in a new thread In-Reply-To: <043.6592bef53ac65bee0d2fb3f8ebb3e3fe@haskell.org> References: <043.6592bef53ac65bee0d2fb3f8ebb3e3fe@haskell.org> Message-ID: <058.e7ec861690ec8dd8312eaa620372a637@haskell.org> #441: GHCi doesn't run computations in a new thread -------------------------------------+--------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.4.2 Component: GHCi | Version: 6.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | -------------------------------------+--------------------------------- Comment (by simonmar ): In [changeset:"2e8bfab959f929ac795d0d2ac64c0446c19e183e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2e8bfab959f929ac795d0d2ac64c0446c19e183e" [project @ 2006-01-12 16:03:21 by simonmar] add test from ticket #441 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:38 -0000 Subject: [GHC] #488: panic! 'impossible' happened, thread blocked indefinitely In-Reply-To: <045.f3a65366b0e03eac278a76bf21882d12@haskell.org> References: <045.f3a65366b0e03eac278a76bf21882d12@haskell.org> Message-ID: <060.abb8fd84461fc3e06504cc82fed75b1c@haskell.org> #488: panic! 'impossible' happened, thread blocked indefinitely -------------------------------------+--------------------------------- Reporter: nobody | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.4.2 Component: GHCi | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | -------------------------------------+--------------------------------- Comment (by simonmar ): In [changeset:"fa931a0715faf64be8f5dc674cf869b587d4189a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fa931a0715faf64be8f5dc674cf869b587d4189a" [project @ 2006-01-12 16:10:41 by simonmar] Add test from ticket #488 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:38 -0000 Subject: [GHC] #661: Serious Data.HashTable bug In-Reply-To: <057.b31dce27f03c04ed28a019a7a7b1aa9c@haskell.org> References: <057.b31dce27f03c04ed28a019a7a7b1aa9c@haskell.org> Message-ID: <072.ce3e88de77ce392a03229ba8f365426b@haskell.org> #661: Serious Data.HashTable bug -------------------------------------+--------------------------------- Reporter: jwr@? | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.4.2 Component: libraries/base | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | -------------------------------------+--------------------------------- Comment (by Simon Marlow ): In [changeset:"418362a2409919eb65eb3d668aaafea74cc7dedf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="418362a2409919eb65eb3d668aaafea74cc7dedf" add test for bug #661 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:38 -0000 Subject: [GHC] #685: Panic splitTyConApp a{tv a1nD} when dealing with GADTs in optimizing mode In-Reply-To: <056.e53b2ac72b76a8b0d67f078ddf7d64a8@haskell.org> References: <056.e53b2ac72b76a8b0d67f078ddf7d64a8@haskell.org> Message-ID: <071.8ce2c6f9336425686e0a09c8494c84b9@haskell.org> #685: Panic splitTyConApp a{tv a1nD} when dealing with GADTs in optimizing mode ------------------------------+----------------------- Reporter: alcremi@? | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Difficulty: Unknown | ------------------------------+----------------------- Comment (by simonpj ): In [changeset:"ba72db2f52ff87be17342464228f4dd2f9140544/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ba72db2f52ff87be17342464228f4dd2f9140544" Add test for bug 685 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:39 -0000 Subject: [GHC] #713: SMP + FFI = crash... In-Reply-To: <059.db4d48ca86375d025075f66289fcd570@haskell.org> References: <059.db4d48ca86375d025075f66289fcd570@haskell.org> Message-ID: <074.d041b19356df22a6d7498c28bded6045@haskell.org> #713: SMP + FFI = crash... -----------------------------------+------------------------------ Reporter: lipeng@? | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.6 Component: Runtime System | Version: 6.5 Resolution: fixed | Keywords: smp ffi crash Operating System: Linux | Architecture: x86 Difficulty: Unknown | -----------------------------------+------------------------------ Comment (by Simon Marlow ): In [changeset:"75eef481fea3b65cf2b842ad441cd33992304394/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="75eef481fea3b65cf2b842ad441cd33992304394" add test for #713 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:40 -0000 Subject: [GHC] #799: runtime error when using par/seq in a monad In-Reply-To: <060.d5600e3ec93980df3e5525e60467a6dc@haskell.org> References: <060.d5600e3ec93980df3e5525e60467a6dc@haskell.org> Message-ID: <075.f49daba6ae9e6c06635d7338af96c8da@haskell.org> #799: runtime error when using par/seq in a monad -------------------------------------+--------------------------------- Reporter: mafuchs@? | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | -------------------------------------+--------------------------------- Comment (by Simon Marlow ): In [changeset:"53565e8f4672f68c051bbe3668cb0bb00bfec585/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="53565e8f4672f68c051bbe3668cb0bb00bfec585" add test from #799 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:41 -0000 Subject: [GHC] #795: ghc-6.5.20060607: panic! (the 'impossible' happened) ... initC: srt In-Reply-To: <056.96478bf9ba36d363ab52ef44c6f6905f@haskell.org> References: <056.96478bf9ba36d363ab52ef44c6f6905f@haskell.org> Message-ID: <071.730fa2add6b56337dd5948a4ea80fcf8@haskell.org> #795: ghc-6.5.20060607: panic! (the 'impossible' happened) ... initC: srt -----------------------------+----------------------- Reporter: ravi@? | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6 Component: Compiler | Version: 6.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Difficulty: Unknown | -----------------------------+----------------------- Comment (by simonpj ): In [changeset:"0b9beed359006db9d4b1a97b77bdddf780a465e1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0b9beed359006db9d4b1a97b77bdddf780a465e1" Test Trac bug #795 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:42 -0000 Subject: [GHC] #876: Length is not a good consumer In-Reply-To: <054.b373028d5cb568a8380002fb5d2d74f4@haskell.org> References: <054.b373028d5cb568a8380002fb5d2d74f4@haskell.org> Message-ID: <069.cf7d8f92ffaa71c89f41a6f41f61be69@haskell.org> #876: Length is not a good consumer --------------------------------------------+------------------------------ Reporter: ariep@? | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: fixed | Keywords: length Operating System: Linux | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: perf/should_run/T876 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Ian Lynagh ): In [changeset:"fb9a2203f1964c465189c12832650df2d234fb9e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fb9a2203f1964c465189c12832650df2d234fb9e" Add a test for length not causing a stack overflow (from #876) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:43 -0000 Subject: [GHC] #902: Deriving for H98 types using GADT syntax fails In-Reply-To: <062.1cc0384d784d48e8da5dc5a70c926c68@haskell.org> References: <062.1cc0384d784d48e8da5dc5a70c926c68@haskell.org> Message-ID: <077.6af1043ed1bd704bed6e2727391e6319@haskell.org> #902: Deriving for H98 types using GADT syntax fails -------------------------------------+--------------------------------- Reporter: bringert@? | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | -------------------------------------+--------------------------------- Comment (by bjorn ): In [changeset:"d378a01f454f0645459903d838fde091791c6e35/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d378a01f454f0645459903d838fde091791c6e35" Added test for ticket #902, deriving for GADTs which declare H98 types fails. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:44 -0000 Subject: [GHC] #37: instance Eq IOError missing In-Reply-To: <045.dd857e81273fd0ce27810c071a507c04@haskell.org> References: <045.dd857e81273fd0ce27810c071a507c04@haskell.org> Message-ID: <060.d17843eda00ae8ea14664eaa964dea68@haskell.org> #37: instance Eq IOError missing ----------------------+---------------------- Reporter: nobody | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 5.02 Resolution: Fixed | Keywords: ----------------------+---------------------- Comment (by simonpj ): In [changeset:"ec1021060d9b8c05a27e481dccdf404d1dcf571e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ec1021060d9b8c05a27e481dccdf404d1dcf571e" Add test for Hugs #37 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:45 -0000 Subject: [GHC] #867: Integer arithmetic gives the wrong answer on amd64/Linux In-Reply-To: <044.9ca4439c1155a006cdebfffd89ab12ff@haskell.org> References: <044.9ca4439c1155a006cdebfffd89ab12ff@haskell.org> Message-ID: <059.552427865a39064b621c25b2e939aa57@haskell.org> #867: Integer arithmetic gives the wrong answer on amd64/Linux -----------------------------+------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Difficulty: Unknown | -----------------------------+------------------------------- Comment (by Ian Lynagh ): In [changeset:"52eb09cc2e96f62143436958e493b37d43292f84/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="52eb09cc2e96f62143436958e493b37d43292f84" Add a test for trac #867 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:45 -0000 Subject: [GHC] #830: Compiler performance bug: large "do" expression In-Reply-To: <047.dba8a5d9495f5ecd1d949f50c0584beb@haskell.org> References: <047.dba8a5d9495f5ecd1d949f50c0584beb@haskell.org> Message-ID: <062.862206b50c311d0159b6aa72c416a3db@haskell.org> #830: Compiler performance bug: large "do" expression -------------------------------------+--------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | -------------------------------------+--------------------------------- Comment (by Simon Marlow ): In [changeset:"c186ff3a58ff59aff0957ef210cffd9fb7c4a4ba/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c186ff3a58ff59aff0957ef210cffd9fb7c4a4ba" add test for #830 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:46 -0000 Subject: [GHC] #906: "the `impossible' happened: Maybe.fromJust: Nothing" when using {-# SOURCE #-} In-Reply-To: <070.8bdfdf269c0c51d09020a1bd860e50d6@haskell.org> References: <070.8bdfdf269c0c51d09020a1bd860e50d6@haskell.org> Message-ID: <085.70c6f0553bbfd7563415fdd0147b143f@haskell.org> #906: "the `impossible' happened: Maybe.fromJust: Nothing" when using {-# SOURCE #-} -----------------------------------------------+------------------------- Reporter: Misha Aizatulin | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.6 Component: Compiler | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Difficulty: Unknown | -----------------------------------------------+------------------------- Comment (by Simon Marlow ): In [changeset:"c26f435608114fd5ae032d503383f2b29e87bd3a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c26f435608114fd5ae032d503383f2b29e87bd3a" add test for #906 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:46 -0000 Subject: [GHC] #919: Cryptic type error message (should be syntax error) In-Reply-To: <067.cde5b29bb40efffdcc8bb798142b2d0b@haskell.org> References: <067.cde5b29bb40efffdcc8bb798142b2d0b@haskell.org> Message-ID: <082.7e72473fa599f72ebc0dc4390b718ac1@haskell.org> #919: Cryptic type error message (should be syntax error) --------------------------------------------+------------------------------ Reporter: josef.svenningsson@? | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.1 Component: Compiler (Type checker) | Version: 6.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Difficulty: Easy (less than 1 hour) | Unknown/Multiple | Test Case: --------------------------------------------+------------------------------ Comment (by simonpj ): In [changeset:"b2d6de1c9204786b63c3694a97ed5ea420b14be5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b2d6de1c9204786b63c3694a97ed5ea420b14be5" Add test for Trac #919 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:47 -0000 Subject: [GHC] #921: Floating point with -O and -fasm is broken In-Reply-To: <044.d0d662d627d0c5404759fa0cb97593ad@haskell.org> References: <044.d0d662d627d0c5404759fa0cb97593ad@haskell.org> Message-ID: <059.fecbda6dd522ce04e8b65f10e8f9cbed@haskell.org> #921: Floating point with -O and -fasm is broken -----------------------------------+------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler (NCG) | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Difficulty: Unknown | Test Case: -----------------------------------+------------------------------- Comment (by Ian Lynagh ): In [changeset:"86a543fe45add9a0e89366a81064a0e65b782e81/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="86a543fe45add9a0e89366a81064a0e65b782e81" Test for trac #921 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:48 -0000 Subject: [GHC] #149: missed CSE opportunity In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> References: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> Message-ID: <060.a020d22771167c9c5d61e3a4a74d991b@haskell.org> #149: missed CSE opportunity -------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: T149 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Ian Lynagh ): In [changeset:"ee40de9386961639e9520dee372688183b26aa5e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ee40de9386961639e9520dee372688183b26aa5e" Test for #149 (missed CSE opportunity) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:48 -0000 Subject: [GHC] #210: .lhs Birdtracks are removed instead of replaced In-Reply-To: <044.1ca90000f161ea607965fbe4d6f8df68@haskell.org> References: <044.1ca90000f161ea607965fbe4d6f8df68@haskell.org> Message-ID: <059.5d6c6623ac1edf2cf4a1f506ef8c5d5d@haskell.org> #210: .lhs Birdtracks are removed instead of replaced --------------------------------------+--------------------------------- Reporter: pesco | Owner: nobody Type: bug | Status: closed Priority: lowest | Milestone: 6.8.1 Component: Compiler (Parser) | Version: 6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | --------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"04f38aeb176d7a57268fd9bcdb26f5ec228ef970/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="04f38aeb176d7a57268fd9bcdb26f5ec228ef970" Add test for correct unlitting. Tests trac #210. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:50 -0000 Subject: [GHC] #249: -caf-all bugs In-Reply-To: <047.d08e83a6365f7648be0b7bf0ed32497f@haskell.org> References: <047.d08e83a6365f7648be0b7bf0ed32497f@haskell.org> Message-ID: <062.67eea0e36a1391c0f6655317bedc6a27@haskell.org> #249: -caf-all bugs -------------------------------------+--------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: low | Milestone: 6.6.1 Component: Profiling | Version: 6.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: prof001 prof002 -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"0b4b8c0af0acf175ceac7281c86a6d0b61be7a4b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0b4b8c0af0acf175ceac7281c86a6d0b61be7a4b" Add tests for trac#249 and #931 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:51 -0000 Subject: [GHC] #931: -caf-all gives "Error: symbol `Mainmain_CAF_cc_ccs' is already defined" In-Reply-To: <044.03647f6caba5b1f42125225524829faf@haskell.org> References: <044.03647f6caba5b1f42125225524829faf@haskell.org> Message-ID: <059.039f38e7ceeb3fba05cb0aa1d0b217be@haskell.org> #931: -caf-all gives "Error: symbol `Mainmain_CAF_cc_ccs' is already defined" ------------------------------+--------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Profiling | Version: 6.5 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Difficulty: Unknown | ------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"0b4b8c0af0acf175ceac7281c86a6d0b61be7a4b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0b4b8c0af0acf175ceac7281c86a6d0b61be7a4b" Add tests for trac#249 and #931 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:52 -0000 Subject: [GHC] #940: GADT + impredicative polymorphism => stack overflow In-Reply-To: <044.601d201067b860a631a358e058890006@haskell.org> References: <044.601d201067b860a631a358e058890006@haskell.org> Message-ID: <059.039164ab9075506252978e9c03070fd7@haskell.org> #940: GADT + impredicative polymorphism => stack overflow --------------------------------------------+------------------------------ Reporter: guest | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Difficulty: Unknown | Unknown/Multiple | Test Case: --------------------------------------------+------------------------------ Comment (by simonpj ): In [changeset:"e80ab122b5209af0cad7e651ee2589b2d9b4d32d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e80ab122b5209af0cad7e651ee2589b2d9b4d32d" Test for Trac #940 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:53 -0000 Subject: [GHC] #314: #line pragmas not respected inside nested comments In-Reply-To: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> References: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> Message-ID: <060.f2f22412a18c1f299fd67363e6e177f7@haskell.org> #314: #line pragmas not respected inside nested comments --------------------------------------+------------------------------------ Reporter: nobody | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 6.4 Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: read032 | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Ian Lynagh ): In [changeset:"1433233503b737076913c7a96b6b31edd550c82f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1433233503b737076913c7a96b6b31edd550c82f" Add a test for trac #314 (#line pragmas not respected inside nested comments) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:53 -0000 Subject: [GHC] #322: fromInteger-related pattern match overlap warnings In-Reply-To: <047.ace5220e5df89abf8e6e92924cc2e86b@haskell.org> References: <047.ace5220e5df89abf8e6e92924cc2e86b@haskell.org> Message-ID: <062.3e2ca3f29e12ce89a701edda356a648a@haskell.org> #322: fromInteger-related pattern match overlap warnings -------------------------------------+------------------------------------ Reporter: ashley-y | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4 Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ds060 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Ian Lynagh ): In [changeset:"50e451242b50bd57c5ad6268b97f6a480c24fe32/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="50e451242b50bd57c5ad6268b97f6a480c24fe32" Add test ds060 for trac #322 (bogus overlapping patterns warnings) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:43 -0000 Subject: [GHC] #900: SPECIALISE broken In-Reply-To: <047.b3124bf07c4f3b1b3048620cc583b632@haskell.org> References: <047.b3124bf07c4f3b1b3048620cc583b632@haskell.org> Message-ID: <062.cadec0149a1c53a864d3b13fad8bfd11@haskell.org> #900: SPECIALISE broken -------------------------------------+--------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6 Component: Compiler | Version: 6.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | -------------------------------------+--------------------------------- Comment (by simonpj ): In [changeset:"b8e14b39343fdd5f62e56a0a4b789757fcf62d12/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b8e14b39343fdd5f62e56a0a4b789757fcf62d12" Add test for Trac #900 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:54 -0000 Subject: [GHC] #366: incomplete patterns and GADT In-Reply-To: <045.78fabe56a37c24d921b345c081d108ef@haskell.org> References: <045.78fabe56a37c24d921b345c081d108ef@haskell.org> Message-ID: <060.5d4e51888cf97b2259cc33f3742381cd@haskell.org> #366: incomplete patterns and GADT -------------------------+------------------------------------------------- Reporter: | Owner: nobody | Status: closed Type: | Milestone: _|_ feature request | Version: None Priority: | Keywords: normal | Architecture: Unknown/Multiple Component: | Test Case: tc215, Compiler | deSugar/should_compile/GadtOverlap Resolution: | fixed | Operating System: | Unknown/Multiple | Difficulty: | Unknown | -------------------------+------------------------------------------------- Comment (by Ian Lynagh ): In [changeset:"81ea2c04dd97f12297d01aa4e2dc338b9346f38a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="81ea2c04dd97f12297d01aa4e2dc338b9346f38a" Tests for trac #366 (incomplete pattern warnings and GADTs) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:55 -0000 Subject: [GHC] #414: GHC does not eforce that Main exports main In-Reply-To: <046.38fe8da23abfc42f9ad2cb0e14b8afda@haskell.org> References: <046.38fe8da23abfc42f9ad2cb0e14b8afda@haskell.org> Message-ID: <061.3b329a7823dde869d9cc8cc49f9fb92e@haskell.org> #414: GHC does not eforce that Main exports main -------------------------------------+--------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: lowest | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: mod174 | -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"5a54c38e846dd4774b0a0cf285d12b353bfcb864/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5a54c38e846dd4774b0a0cf285d12b353bfcb864" Add test mod174 for trac #414 (GHC does not enforce that Main exports main) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:56 -0000 Subject: [GHC] #481: Recompilation check fails for TH In-Reply-To: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> References: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> Message-ID: <061.9d30f533e1e3b70c2b1f6663d880c48a@haskell.org> #481: Recompilation check fails for TH ------------------------------------------------+-------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: TH_recompile | Difficulty: Unknown Blocking: | Blocked By: ------------------------------------------------+-------------------------- Comment (by Ian Lynagh ): In [changeset:"27d0701d92b71c29f5260998d7579e60611ef87d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="27d0701d92b71c29f5260998d7579e60611ef87d" Add test TH_recompile for trac #481 (Recompilation check fails for TH) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:57 -0000 Subject: [GHC] #552: GHCi :m doesn't restore default decl In-Reply-To: <046.8fe84617c76248de33d1df0f58763c7d@haskell.org> References: <046.8fe84617c76248de33d1df0f58763c7d@haskell.org> Message-ID: <061.f12439da4f67f0d2b9a5de0adc54c384@haskell.org> #552: GHCi :m doesn't restore default decl -------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: GHCi | Version: 5.0 Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: ghci016 -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"62a700a293b1003f3f6d18630846692cedbdb9ca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="62a700a293b1003f3f6d18630846692cedbdb9ca" Add test ghci016 for trac #552 (ghci doesn't handle defaults correctly). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:58 -0000 Subject: [GHC] #629: IO library locking doesn't count readers In-Reply-To: <047.f53579f0eef5f0620161448899a49782@haskell.org> References: <047.f53579f0eef5f0620161448899a49782@haskell.org> Message-ID: <062.966b87634bf8ae78301bc54435938645@haskell.org> #629: IO library locking doesn't count readers -------------------------------------+--------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: lowest | Milestone: 6.8.3 Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: countReaders001 -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"10db1142747ca19617574d2880f9fb16de33be0e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="10db1142747ca19617574d2880f9fb16de33be0e" Add test countReaders001 for trac #629 (file locking doesn't count readers) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:59 -0000 Subject: [GHC] #719: error messages are too long sometimes In-Reply-To: <047.3232e33428994224a390309ce7095c39@haskell.org> References: <047.3232e33428994224a390309ce7095c39@haskell.org> Message-ID: <062.8cd72ebec6ad949743565b35de14ea99@haskell.org> #719: error messages are too long sometimes --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Difficulty: Easy (less than 1 hour) | Unknown/Multiple | Test Case: tcfail168 --------------------------------------------+------------------------------ Comment (by Ian Lynagh ): In [changeset:"20c2f57dd6da7177ac7b99eeccef5c27b150beda/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="20c2f57dd6da7177ac7b99eeccef5c27b150beda" Add test tcfail168 for trac #719 (error messages are too long sometimes) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:00:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:00:59 -0000 Subject: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs In-Reply-To: <044.a73c522b97030f99c5fa39d521657f06@haskell.org> References: <044.a73c522b97030f99c5fa39d521657f06@haskell.org> Message-ID: <059.42347ee44606bae757b65594a7104125@haskell.org> #781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 6.5 Resolution: | Keywords: getEnvironment Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: getEnvironment01 | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Ian Lynagh ): In [changeset:"d64c1b96fb7e6778c421fe4b2d5ee3a5cc433e98/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d64c1b96fb7e6778c421fe4b2d5ee3a5cc433e98" Add test getEnvironment01 for trac #781 (check getEnvironment doesn't break) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:00 -0000 Subject: [GHC] #810: GHC complains about missing instance in conjunction with GADTs In-Reply-To: <059.d125c1160e52f549fd2ce0b9538c0e54@haskell.org> References: <059.d125c1160e52f549fd2ce0b9538c0e54@haskell.org> Message-ID: <074.7c51bc5947ada362aff90acb9d23ad67@haskell.org> #810: GHC complains about missing instance in conjunction with GADTs -------------------------------+------------------------ Reporter: wolfgang@? | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.8.1 Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Difficulty: Unknown | Test Case: gadt20 -------------------------------+------------------------ Comment (by Ian Lynagh ): In [changeset:"5a6c7d62ae6fe2f264b8734f91bd75c58c56600e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5a6c7d62ae6fe2f264b8734f91bd75c58c56600e" Add test gadt20 for trac #810 (GHC fails to find GADT instances) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:02 -0000 Subject: [GHC] #816: Weird fundep behavior (with -fallow-undecidable-instances) In-Reply-To: <044.3c70b416f57f6840427c7f7466886ae7@haskell.org> References: <044.3c70b416f57f6840427c7f7466886ae7@haskell.org> Message-ID: <059.96b64f88867e39109345e498f3049069@haskell.org> #816: Weird fundep behavior (with -fallow-undecidable-instances) -------------------------------------------------+------------------------- Reporter: nibro | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown typecheck/should_compile/tc216, indexed- | Blocked By: types/should_compile/Gentle | Blocking: | -------------------------------------------------+------------------------- Comment (by Ian Lynagh ): In [changeset:"9218ce88678ebb16913fbc32462bdb57f7774799/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9218ce88678ebb16913fbc32462bdb57f7774799" Add test tc216 for trac #816 (fundep undecidable-instances typechecking loop) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:03 -0000 Subject: [GHC] #851: Incomplete-pattern checking for n+k patterns is not implemented In-Reply-To: <046.dfba11239564563edf19c7b91679aa5b@haskell.org> References: <046.dfba11239564563edf19c7b91679aa5b@haskell.org> Message-ID: <061.45495ba3b1a2355e443e90b10ff6f148@haskell.org> #851: Incomplete-pattern checking for n+k patterns is not implemented -------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: wontfix | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ds061 | -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"58352225f6808b918f7f41ac8596712e68fcf23a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="58352225f6808b918f7f41ac8596712e68fcf23a" Add test ds061 for trac #851 (incomplete pattern warnings wrong with n+k pats) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:04 -0000 Subject: [GHC] #963: monadic Num instance not found in ghci In-Reply-To: <055.6ea5f6a0ca23c773e390402e912e1530@haskell.org> References: <055.6ea5f6a0ca23c773e390402e912e1530@haskell.org> Message-ID: <070.001f99118d093175c1d27756fb780da6@haskell.org> #963: monadic Num instance not found in ghci --------------------------------+----------------------- Reporter: rwxr-xr-x@? | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.6 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Difficulty: Unknown | Test Case: tc217 --------------------------------+----------------------- Comment (by simonpj ): In [changeset:"acaaff0a1cbea03b8fe16825e78b455af5dec4d3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="acaaff0a1cbea03b8fe16825e78b455af5dec4d3" Add test for Trac #963 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:05 -0000 Subject: [GHC] #971: Add intercalate to Data.List In-Reply-To: <044.56536af2dcc27289cb2045b25506dbd7@haskell.org> References: <044.56536af2dcc27289cb2045b25506dbd7@haskell.org> Message-ID: <059.930fad6eee1b5c48b0e873a0da4d74f1@haskell.org> #971: Add intercalate to Data.List -------------------------------------+--------------------------------- Reporter: josef | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: -------------------------------------+--------------------------------- Comment (by Josef Svenningsson ): In [changeset:"d40e957486043606b76e3cd60d541131e71085a4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d40e957486043606b76e3cd60d541131e71085a4" Add tests for Data.List.intercalate (ticket #971) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:05 -0000 Subject: [GHC] #953: panic in ghci for lseek ffi import statement In-Reply-To: <055.d63527b6a5ce271f4fba02ab316984b9@haskell.org> References: <055.d63527b6a5ce271f4fba02ab316984b9@haskell.org> Message-ID: <070.c2c13d902254a75095f4a87f41e7d5bc@haskell.org> #953: panic in ghci for lseek ffi import statement --------------------------------+------------------------------ Reporter: rwxr-xr-x@? | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: GHCi | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Difficulty: Unknown | Test Case: ffi017 ffi018 --------------------------------+------------------------------ Comment (by Ian Lynagh ): In [changeset:"31836e4b944f67f64197aaa45d5d0e1718b3a9fe/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="31836e4b944f67f64197aaa45d5d0e1718b3a9fe" Add test for trac #953: panic in ghci for lseek ffi import statement }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:06 -0000 Subject: [GHC] #301: GADT constructor constraints ignored In-Reply-To: <051.cd5ec36b1043042945a2790044e168e3@haskell.org> References: <051.cd5ec36b1043042945a2790044e168e3@haskell.org> Message-ID: <066.e5bd3cd92558c16931162a1364051c49@haskell.org> #301: GADT constructor constraints ignored -------------------------------------+------------------------------------- Reporter: wolfram_kahl | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.8.1 Component: Compiler (Type | Version: 6.4 checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Test Case: gadt/karl1, Difficulty: Unknown | gadt/karl2 -------------------------------------+------------------------------------- Comment (by simonpj ): In [changeset:"e9741fd3a5412fd9c8ef9985973d0bde20e525ce/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e9741fd3a5412fd9c8ef9985973d0bde20e525ce" Add two GADT tests for Trac #301, fixed by implication constraints }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:07 -0000 Subject: [GHC] #289: class context restrictions in GADT types not assumed In-Reply-To: <047.ae04e821601e3b18c51456fdf92812ce@haskell.org> References: <047.ae04e821601e3b18c51456fdf92812ce@haskell.org> Message-ID: <062.d6098ffa4fd28402a5c479debb0fc2bd@haskell.org> #289: class context restrictions in GADT types not assumed -------------------------------------+------------------------------------- Reporter: ashley-y | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.8.1 Component: Compiler (Type | Version: 6.4 checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Test Case: gadt/data1, Difficulty: Unknown | gadt/data2 -------------------------------------+------------------------------------- Comment (by simonpj ): In [changeset:"31fbae749fc0e67b48d490349dfa6279881e6414/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="31fbae749fc0e67b48d490349dfa6279881e6414" Tests for Trac #289 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:08 -0000 Subject: [GHC] #1013: interpretBCO: unknown or unimplemented opcode 64356 In-Reply-To: <043.b7a9369cedc709aa64a45d9402069456@haskell.org> References: <043.b7a9369cedc709aa64a45d9402069456@haskell.org> Message-ID: <058.f18a059fa5e750b4390e5373d5bcce95@haskell.org> #1013: interpretBCO: unknown or unimplemented opcode 64356 -------------------------------------+--------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.6.1 Component: GHCi | Version: 6.6 Resolution: fixed | Keywords: "OS X" Sockets Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: ghci002 -------------------------------------+--------------------------------- Comment (by Simon Marlow ): In [changeset:"b838de58e4ea71ff525501aa9e073839582a71c4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b838de58e4ea71ff525501aa9e073839582a71c4" add test for #1013 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:09 -0000 Subject: [GHC] #1001: "ghc-6.6: panic! (the 'impossible' happened) interactiveUI:flush" when hiding haskell98 and importing IO In-Reply-To: <065.0517697a8908f52ff91ead4af68a8dee@haskell.org> References: <065.0517697a8908f52ff91ead4af68a8dee@haskell.org> Message-ID: <080.cdc1b63ad0265b0c63cac37052da7afb@haskell.org> #1001: "ghc-6.6: panic! (the 'impossible' happened) interactiveUI:flush" when hiding haskell98 and importing IO ----------------------------------------+------------------------------- Reporter: benjamin.franksen@? | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Difficulty: Unknown | Test Case: ghci017 ----------------------------------------+------------------------------- Comment (by Ian Lynagh ): In [changeset:"f70f94264ac724721c540a2e60175f551f8103b3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f70f94264ac724721c540a2e60175f551f8103b3" Check running ghci with -hide-package haskell98 works. Tests trac #1001. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:10 -0000 Subject: [GHC] #1033: ghc-6.7: panic! (the 'impossible' happened) -- typechecker getting confused by Data.Generics? In-Reply-To: <044.3ab031d337f010a0124134caabfb506b@haskell.org> References: <044.3ab031d337f010a0124134caabfb506b@haskell.org> Message-ID: <059.57aaa91ad1edb771dc145742eff04704@haskell.org> #1033: ghc-6.7: panic! (the 'impossible' happened) -- typechecker getting confused by Data.Generics? -------------------------------------+--------------------------------- Reporter: int-e | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: tc220 -------------------------------------+--------------------------------- Comment (by simonpj ): In [changeset:"fbdb1520c3bb5048cbe257cd14a96a6dc8e1da2e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fbdb1520c3bb5048cbe257cd14a96a6dc8e1da2e" Add test for Trac #1033 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:12 -0000 Subject: [GHC] #1052: NCG doesn't realise shift instructions trash shifted input? In-Reply-To: <044.0899c35998d989be09a14cb24bcdb5a2@haskell.org> References: <044.0899c35998d989be09a14cb24bcdb5a2@haskell.org> Message-ID: <059.fb66addf71485e9a9c0250884d9de32f@haskell.org> #1052: NCG doesn't realise shift instructions trash shifted input? -----------------------------------+------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.8.1 Component: Compiler (NCG) | Version: 6.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Difficulty: Unknown | Test Case: arith011 -----------------------------------+------------------------------- Comment (by Ian Lynagh ): In [changeset:"11bc6605dd9bf3605fcab02afe79570c064d5047/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="11bc6605dd9bf3605fcab02afe79570c064d5047" arith011 is broken on amd64 Linux; trac #1052 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:13 -0000 Subject: [GHC] #629: IO library locking doesn't count readers In-Reply-To: <047.f53579f0eef5f0620161448899a49782@haskell.org> References: <047.f53579f0eef5f0620161448899a49782@haskell.org> Message-ID: <062.f6bdd042ac38e27eedd8ff850b770d62@haskell.org> #629: IO library locking doesn't count readers -------------------------------------+--------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: lowest | Milestone: 6.8.3 Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: countReaders001 -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"35aa7715ad158432ea8529c25705ea874b2d3157/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="35aa7715ad158432ea8529c25705ea874b2d3157" countReaders001 is broken - trac #629 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:14 -0000 Subject: [GHC] #322: fromInteger-related pattern match overlap warnings In-Reply-To: <047.ace5220e5df89abf8e6e92924cc2e86b@haskell.org> References: <047.ace5220e5df89abf8e6e92924cc2e86b@haskell.org> Message-ID: <062.562229d6ec9074dde6e492c21ed0971f@haskell.org> #322: fromInteger-related pattern match overlap warnings -------------------------------------+------------------------------------ Reporter: ashley-y | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4 Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ds060 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Ian Lynagh ): In [changeset:"fef7a82c6897afb5196ca91a097c5d6b2462d4b7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fef7a82c6897afb5196ca91a097c5d6b2462d4b7" ds060 and ds061 are broken: trac #322, #851 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:09 -0000 Subject: [GHC] #1041: Bang patterns in do notation and lambdas In-Reply-To: <043.54c5c6e39350305c0d5a74c7b9af6593@haskell.org> References: <043.54c5c6e39350305c0d5a74c7b9af6593@haskell.org> Message-ID: <058.50567b78cb3735a12f9ebf7a495537f0@haskell.org> #1041: Bang patterns in do notation and lambdas --------------------------------------------+------------------------------ Reporter: dons | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.6 Resolution: fixed | Keywords: bang patterns Operating System: Unknown/Multiple | Architecture: Difficulty: Easy (less than 1 hour) | Unknown/Multiple | Test Case: read042 --------------------------------------------+------------------------------ Comment (by simonpj ): In [changeset:"3a87e343e060bec31f42cb4b393ea6b07b25efac/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3a87e343e060bec31f42cb4b393ea6b07b25efac" Add bang-pattern test Fixes Trac #1041 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:15 -0000 Subject: [GHC] #851: Incomplete-pattern checking for n+k patterns is not implemented In-Reply-To: <046.dfba11239564563edf19c7b91679aa5b@haskell.org> References: <046.dfba11239564563edf19c7b91679aa5b@haskell.org> Message-ID: <061.e0e4b875bad42354f19964da19e85954@haskell.org> #851: Incomplete-pattern checking for n+k patterns is not implemented -------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: wontfix | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ds061 | -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"fef7a82c6897afb5196ca91a097c5d6b2462d4b7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fef7a82c6897afb5196ca91a097c5d6b2462d4b7" ds060 and ds061 are broken: trac #322, #851 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:16 -0000 Subject: [GHC] #179: Instance match failure on openTypeKind In-Reply-To: <046.3d0f700b77c360c7a0637639cbd25d3a@haskell.org> References: <046.3d0f700b77c360c7a0637639cbd25d3a@haskell.org> Message-ID: <061.fee06eaf7abafaebdce8df22a84021ed@haskell.org> #179: Instance match failure on openTypeKind --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.8.1 Component: Compiler (Type checker) | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Difficulty: Unknown | Unknown/Multiple | Test Case: tc175 --------------------------------------------+------------------------------ Comment (by Ian Lynagh ): In [changeset:"837aafa66533f44e0cbc83235048c5ff1beeeeb6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="837aafa66533f44e0cbc83235048c5ff1beeeeb6" tc175 / trac #179 fixed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:17 -0000 Subject: [GHC] #437: Recompilation check should include flags In-Reply-To: <046.9be6e1c5effc47bf45f5c9a62716ae81@haskell.org> References: <046.9be6e1c5effc47bf45f5c9a62716ae81@haskell.org> Message-ID: <061.5ad805e0961238f40c790a65daa95009@haskell.org> #437: Recompilation check should include flags -------------------------------------+--------------------------------- Reporter: simonpj | Owner: dterei Type: bug | Status: closed Priority: low | Milestone: 7.4.1 Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: mod175 | Blocked By: Blocking: | -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"49ca979dc07fb0bfb9a790630cb2eb41750a96bd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="49ca979dc07fb0bfb9a790630cb2eb41750a96bd" mod174/mod175 are broken: trac bugs #414 and #437 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:18 -0000 Subject: [GHC] #414: GHC does not eforce that Main exports main In-Reply-To: <046.38fe8da23abfc42f9ad2cb0e14b8afda@haskell.org> References: <046.38fe8da23abfc42f9ad2cb0e14b8afda@haskell.org> Message-ID: <061.e26e895317c5b5f70d3252dd6811c4f3@haskell.org> #414: GHC does not eforce that Main exports main -------------------------------------+--------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: lowest | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: mod174 | -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"49ca979dc07fb0bfb9a790630cb2eb41750a96bd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="49ca979dc07fb0bfb9a790630cb2eb41750a96bd" mod174/mod175 are broken: trac bugs #414 and #437 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:18 -0000 Subject: [GHC] #249: -caf-all bugs In-Reply-To: <047.d08e83a6365f7648be0b7bf0ed32497f@haskell.org> References: <047.d08e83a6365f7648be0b7bf0ed32497f@haskell.org> Message-ID: <062.274466b59887df9d4e0b2ab2bb796c50@haskell.org> #249: -caf-all bugs -------------------------------------+--------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: low | Milestone: 6.6.1 Component: Profiling | Version: 6.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: prof001 prof002 -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"b656db34e57848b44fcc62e4c71b38fe58212394/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b656db34e57848b44fcc62e4c71b38fe58212394" prof001 and prof002 are broken (trac #249) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:19 -0000 Subject: [GHC] #314: #line pragmas not respected inside nested comments In-Reply-To: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> References: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> Message-ID: <060.13b4776d7b7654c93892b3e96d341bde@haskell.org> #314: #line pragmas not respected inside nested comments --------------------------------------+------------------------------------ Reporter: nobody | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 6.4 Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: read032 | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Ian Lynagh ): In [changeset:"63ca28c0316f51aa2b3e23c67e28c4ed66aa165b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="63ca28c0316f51aa2b3e23c67e28c4ed66aa165b" read032 is broken: trac #314 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:20 -0000 Subject: [GHC] #149: missed CSE opportunity In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> References: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> Message-ID: <060.5e37a38187722630bdbec72fe405d45a@haskell.org> #149: missed CSE opportunity -------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: T149 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Ian Lynagh ): In [changeset:"c4068e4df8b23e7f51605bd8db9754fee28b6ff0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c4068e4df8b23e7f51605bd8db9754fee28b6ff0" simplrun006 is broken: trac #149 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:16 -0000 Subject: [GHC] #552: GHCi :m doesn't restore default decl In-Reply-To: <046.8fe84617c76248de33d1df0f58763c7d@haskell.org> References: <046.8fe84617c76248de33d1df0f58763c7d@haskell.org> Message-ID: <061.089b6c169706401403f98d7dbefa2645@haskell.org> #552: GHCi :m doesn't restore default decl -------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: GHCi | Version: 5.0 Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: ghci016 -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"18ed82fe963ca158741c40c3a97a291404bf2079/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="18ed82fe963ca158741c40c3a97a291404bf2079" ghci016 is broken: trac #552 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:22 -0000 Subject: [GHC] #366: incomplete patterns and GADT In-Reply-To: <045.78fabe56a37c24d921b345c081d108ef@haskell.org> References: <045.78fabe56a37c24d921b345c081d108ef@haskell.org> Message-ID: <060.1200408c2afdd3fbadc367b09dbea32c@haskell.org> #366: incomplete patterns and GADT -------------------------+------------------------------------------------- Reporter: | Owner: nobody | Status: closed Type: | Milestone: _|_ feature request | Version: None Priority: | Keywords: normal | Architecture: Unknown/Multiple Component: | Test Case: tc215, Compiler | deSugar/should_compile/GadtOverlap Resolution: | fixed | Operating System: | Unknown/Multiple | Difficulty: | Unknown | -------------------------+------------------------------------------------- Comment (by Ian Lynagh ): In [changeset:"912694f7c03131919a503ddfe72bba9b19c6e903/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="912694f7c03131919a503ddfe72bba9b19c6e903" tc215 is broken: trac #366 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:26 -0000 Subject: [GHC] #1054: Not in scope test failures In-Reply-To: <044.43fb07fdd154abb567530e5e1f0413bb@haskell.org> References: <044.43fb07fdd154abb567530e5e1f0413bb@haskell.org> Message-ID: <059.c57e9d9075f6f4e14a0302eb756d3bb6@haskell.org> #1054: Not in scope test failures -------------------------+------------------------------------------------- Reporter: | Owner: igloo | Status: closed Type: bug | Milestone: 6.8.1 Priority: | Version: 6.7 normal | Keywords: Component: | Architecture: Unknown/Multiple Compiler | Test Case: TH_genEx, TH_repGuard, Resolution: | TH_repGuardOutput, TH_spliceInst, arrowcase1, fixed | cc012, mod49, tcfail077 Operating System: | Unknown/Multiple | Difficulty: | Unknown | -------------------------+------------------------------------------------- Comment (by Ian Lynagh ): In [changeset:"207d82baed90f68b3b128a96692933656fe4d6df/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="207d82baed90f68b3b128a96692933656fe4d6df" Mark tests in trac #1054 as broken }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:27 -0000 Subject: [GHC] #948: Incorrect Core transformations with cost centres In-Reply-To: <047.dc441b66a8c4865066e5c35a3e5cb9aa@haskell.org> References: <047.dc441b66a8c4865066e5c35a3e5cb9aa@haskell.org> Message-ID: <062.9f5a8ce577027f031c069441f33c71f8@haskell.org> #948: Incorrect Core transformations with cost centres -------------------------------------+--------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Profiling | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"54d7da3f5fb10ff7540ec2a6910cce82e6860259/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="54d7da3f5fb10ff7540ec2a6910cce82e6860259" cg057 broken: trac #948. Also fix whitespace. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:28 -0000 Subject: [GHC] #1065: The impossible happened (Template Haskell) In-Reply-To: <056.cd87783b2449aab0d30591073cd411db@haskell.org> References: <056.cd87783b2449aab0d30591073cd411db@haskell.org> Message-ID: <071.2cde2ae2b04d6da9992863b336ddba10@haskell.org> #1065: The impossible happened (Template Haskell) -------------------------------------+--------------------------------- Reporter: sfh23@? | Owner: simonpj Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Template Haskell | Version: 6.6 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: TH_dataD1 -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"a7d78464091e048c25bdd85e98b10f958abe7156/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a7d78464091e048c25bdd85e98b10f958abe7156" Add test TH_dataD1 for trac #1065 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:29 -0000 Subject: [GHC] #1051: Insufficient location information for parse errors before ''module'' keyword In-Reply-To: <046.732167e53fe079847f0df387e852cfe4@haskell.org> References: <046.732167e53fe079847f0df387e852cfe4@haskell.org> Message-ID: <061.3b696933b5b08c2cf87e6ea480afb780@haskell.org> #1051: Insufficient location information for parse errors before ''module'' keyword --------------------------------------------+------------------------------ Reporter: nfrisby | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler (Parser) | Version: 6.6 Resolution: fixed | Keywords: error message Operating System: Unknown/Multiple | Architecture: Difficulty: Easy (less than 1 hour) | Unknown/Multiple | Test Case: --------------------------------------------+------------------------------ Comment (by Ian Lynagh ): In [changeset:"025435977d7e387bef23557398077836a0b85165/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="025435977d7e387bef23557398077836a0b85165" Add test for trac #1051 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:30 -0000 Subject: [GHC] #1054: Not in scope test failures In-Reply-To: <044.43fb07fdd154abb567530e5e1f0413bb@haskell.org> References: <044.43fb07fdd154abb567530e5e1f0413bb@haskell.org> Message-ID: <059.2bcaf018763951c841e8c7e5acc61b88@haskell.org> #1054: Not in scope test failures -------------------------+------------------------------------------------- Reporter: | Owner: igloo | Status: closed Type: bug | Milestone: 6.8.1 Priority: | Version: 6.7 normal | Keywords: Component: | Architecture: Unknown/Multiple Compiler | Test Case: TH_genEx, TH_repGuard, Resolution: | TH_repGuardOutput, TH_spliceInst, arrowcase1, fixed | cc012, mod49, tcfail077 Operating System: | Unknown/Multiple | Difficulty: | Unknown | -------------------------+------------------------------------------------- Comment (by simonpj ): In [changeset:"7dbce82bac9d32d8d3acf62b9008f68a374e9d53/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7dbce82bac9d32d8d3acf62b9008f68a374e9d53" Fix sundry test failures (some of Trac #1054) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:31 -0000 Subject: [GHC] #1067: assertion failure in Schedule.c In-Reply-To: <043.08f4e4aa57df8dd231665a72850389d0@haskell.org> References: <043.08f4e4aa57df8dd231665a72850389d0@haskell.org> Message-ID: <058.06361f829a03308f644e3fdb2b3d02d4@haskell.org> #1067: assertion failure in Schedule.c -----------------------------------+--------------------------------- Reporter: ms43 | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.6 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: -----------------------------------+--------------------------------- Comment (by Simon Marlow ): In [changeset:"19a40cd342f026d9d5384cf8c69178a1052a79a4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="19a40cd342f026d9d5384cf8c69178a1052a79a4" add test for #1067 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:28 -0000 Subject: [GHC] #455: mkProtoBCO: stack use won't fit in 16 bits 79141 In-Reply-To: <047.d6ec5bdb5ccff4ce3c3454408860cc3e@haskell.org> References: <047.d6ec5bdb5ccff4ce3c3454408860cc3e@haskell.org> Message-ID: <062.c50712ac4847cd6342e45c3045eeedde@haskell.org> #455: mkProtoBCO: stack use won't fit in 16 bits 79141 -------------------------------------+--------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: GHCi | Version: 6.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: ghci003 -------------------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"3b2bb065eeea7876fc924b420e16e5dd955400a0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3b2bb065eeea7876fc924b420e16e5dd955400a0" Add test for trac #455 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:32 -0000 Subject: [GHC] #1047: Increase gurantees of semantics of block/unblock/throwTo In-Reply-To: <053.c891d613aa7fe4f9b34e77604411a42d@haskell.org> References: <053.c891d613aa7fe4f9b34e77604411a42d@haskell.org> Message-ID: <068.ac03bf3db2a0f4454427f72bae00b92f@haskell.org> #1047: Increase gurantees of semantics of block/unblock/throwTo -------------------------------------+--------------------------------- Reporter: ChrisKuklewicz | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.6 Resolution: fixed | Keywords: concurrency Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: conc065, conc066 -------------------------------------+--------------------------------- Comment (by Simon Marlow ): In [changeset:"d0d2945bc0d01343ac420276cc81801882bcbe08/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d0d2945bc0d01343ac420276cc81801882bcbe08" tests for #1047 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:33 -0000 Subject: [GHC] #1092: initC: srt when compiling with profiling In-Reply-To: <056.0358fde039c4dbf41fa2da6c42386476@haskell.org> References: <056.0358fde039c4dbf41fa2da6c42386476@haskell.org> Message-ID: <071.63f176bcdbad0b8b55380c308a5554a2@haskell.org> #1092: initC: srt when compiling with profiling -------------------------------------+--------------------------------- Reporter: ravi@? | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: rule1 -------------------------------------+--------------------------------- Comment (by simonpj ): In [changeset:"dcdd1eb0a79d7de411035fe37fa76c00e29e0e35/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dcdd1eb0a79d7de411035fe37fa76c00e29e0e35" Add test for Trac #1092 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:34 -0000 Subject: [GHC] #1042: Floating point exception In-Reply-To: <043.a5be1d72d3d949715655e3ba90022338@haskell.org> References: <043.a5be1d72d3d949715655e3ba90022338@haskell.org> Message-ID: <058.67c5c6de4fc01674ff7a7fe50729e3b4@haskell.org> #1042: Floating point exception -------------------------------------+------------------------ Reporter: dons | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: | Difficulty: Unknown Test Case: | -------------------------------------+------------------------ Comment (by Ian Lynagh ): In [changeset:"90f39e878862a7f0aeb452abf5713f12fddc4d19/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="90f39e878862a7f0aeb452abf5713f12fddc4d19" Add a test for trac #1042 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:35 -0000 Subject: [GHC] #1012: ghc panic with mutually recursive modules and template haskell In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@haskell.org> Message-ID: <059.28dcdf1591ca4a23d0a7981a353893a4@haskell.org> #1012: ghc panic with mutually recursive modules and template haskell -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_import_loop | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Ian Lynagh ): In [changeset:"dbf3b55ff58fc762beef1fc102cb7c6348efac9c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dbf3b55ff58fc762beef1fc102cb7c6348efac9c" Add a test for trac #1012: Problems with TH and recursive module imports }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:36 -0000 Subject: [GHC] #896: GetLastError/SetLastError in Windows In-Reply-To: <047.fd09f3594f4639eb3b39ee650b642762@haskell.org> References: <047.fd09f3594f4639eb3b39ee650b642762@haskell.org> Message-ID: <062.eb068f7b037ea6c3a7a1f1705a378719@haskell.org> #896: GetLastError/SetLastError in Windows --------------------------------------------+------------------------------ Reporter: eivuokko | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Difficulty: Easy (less than 1 hour) | Unknown/Multiple | Test Case: --------------------------------------------+------------------------------ Comment (by Simon Marlow ): In [changeset:"72aefc22ad10eae1b7e766f61da373a41dcba3c5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="72aefc22ad10eae1b7e766f61da373a41dcba3c5" add a test for #896 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:37 -0000 Subject: [GHC] #36: lazy IO In-Reply-To: <048.86035ca67d0fc8ea5006408fb0869e1a@haskell.org> References: <048.86035ca67d0fc8ea5006408fb0869e1a@haskell.org> Message-ID: <063.c4c8b2336aa5373bfd0b0073dbe3cd33@haskell.org> #36: lazy IO ------------------------+-------------------- Reporter: haskeller | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 5.02 Resolution: None | Keywords: ------------------------+-------------------- Comment (by Simon Marlow ): In [changeset:"bb6e9cd0164e7885fe153f0d210ee2d6c2a73d9a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bb6e9cd0164e7885fe153f0d210ee2d6c2a73d9a" add test for bug #036 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:38 -0000 Subject: [GHC] #418: throwTo to a thread inside 'block' In-Reply-To: <044.bf7a58746fbda955e298abdfd4e1a463@haskell.org> References: <044.bf7a58746fbda955e298abdfd4e1a463@haskell.org> Message-ID: <059.350c6a9ecc450d68b5fc96433ed42c4d@haskell.org> #418: throwTo to a thread inside 'block' ------------------------------------------------+-------------------------- Reporter: remit | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Unknown ------------------------------------------------+-------------------------- Comment (by Ian Lynagh ): In [changeset:"48fc4ded46ce262673ea08c61ae7ea296e9f6e1e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="48fc4ded46ce262673ea08c61ae7ea296e9f6e1e" Add a test from #418 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:38 -0000 Subject: [GHC] #1128: The impossible happened, code commented In-Reply-To: <047.05f5e63b1101b2a6115885417e1d3e26@haskell.org> References: <047.05f5e63b1101b2a6115885417e1d3e26@haskell.org> Message-ID: <062.881d47fc66e827211440fec1cf9e8ce3@haskell.org> #1128: The impossible happened, code commented -------------------------------------+--------------------------------- Reporter: humasect | Owner: Type: merge | Status: closed Priority: lowest | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: rn051 -------------------------------------+--------------------------------- Comment (by simonpj ): In [changeset:"f0022b77de6b62a69f646d87ae84da1d476ca15f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f0022b77de6b62a69f646d87ae84da1d476ca15f" Add test for Trac #1128 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:39 -0000 Subject: [GHC] #1010: ghci crashes when running out of heap. In-Reply-To: <057.d39affd08b6e860c76b917287a269343@haskell.org> References: <057.d39affd08b6e860c76b917287a269343@haskell.org> Message-ID: <072.7e5c454274c6b42677f6d907a0db4497@haskell.org> #1010: ghci crashes when running out of heap. ------------------------------+------------------------- Reporter: tullsen@? | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86 Difficulty: Unknown | Test Case: bug10101 ------------------------------+------------------------- Comment (by Simon Marlow ): In [changeset:"1044bd1ae5b1682502c55428dccdaaf3ddce50b4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1044bd1ae5b1682502c55428dccdaaf3ddce50b4" add test for bug #1010 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:40 -0000 Subject: [GHC] #1153: panic! "expectJust zonkSigTyVar" while compiling In-Reply-To: <044.d7c451ba021f946c2312bef5c90a4f8e@haskell.org> References: <044.d7c451ba021f946c2312bef5c90a4f8e@haskell.org> Message-ID: <059.53b9ef9cf97354cb7989b129613c43a4@haskell.org> #1153: panic! "expectJust zonkSigTyVar" while compiling -----------------------------+-------------------------- Reporter: shahn | Owner: simonpj Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Difficulty: Unknown | Test Case: tcfail175 -----------------------------+-------------------------- Comment (by simonpj ): In [changeset:"0e209896342e408b56437c88b3141bfcb26fd5bd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0e209896342e408b56437c88b3141bfcb26fd5bd" Add test for Trac #1153 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:44 -0000 Subject: [GHC] #1128: The impossible happened, code commented In-Reply-To: <047.05f5e63b1101b2a6115885417e1d3e26@haskell.org> References: <047.05f5e63b1101b2a6115885417e1d3e26@haskell.org> Message-ID: <062.a5ab8da53babb3c3b5cbbfc65f8593b7@haskell.org> #1128: The impossible happened, code commented -------------------------------------+--------------------------------- Reporter: humasect | Owner: Type: merge | Status: closed Priority: lowest | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: rn051 -------------------------------------+--------------------------------- Comment (by simonpj ): In [changeset:"60ce42c591b79e5277f7ac9218fe8adcc3747132/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="60ce42c591b79e5277f7ac9218fe8adcc3747132" Test for Trac #1128 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:45 -0000 Subject: [GHC] #1154: GADT syntax for newtype causes tcConDecl exception In-Reply-To: <045.f1453e2d2a106246ab5667f3949f9925@haskell.org> References: <045.f1453e2d2a106246ab5667f3949f9925@haskell.org> Message-ID: <060.683c7d75f2cfd314df294081411c96d2@haskell.org> #1154: GADT syntax for newtype causes tcConDecl exception -----------------------------+--------------------------------- Reporter: ccshan | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: tc225, tcfail176 -----------------------------+--------------------------------- Comment (by simonpj ): In [changeset:"f06d27070a518fdec8752cb1738daea5a3d8bef1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f06d27070a518fdec8752cb1738daea5a3d8bef1" Tests for Trac #1154 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:47 -0000 Subject: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics In-Reply-To: <043.e34c647eb7853d1bfa5f9e817d95be19@haskell.org> References: <043.e34c647eb7853d1bfa5f9e817d95be19@haskell.org> Message-ID: <058.80a8cd92d75a0bb6cd85e2cd225b009f@haskell.org> #1171: GHC doesn't respect the imprecise exceptions semantics -------------------------------------+------------------------------------ Reporter: neil | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: cg059 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Ian Lynagh ): In [changeset:"168c6b2a6559a30f1500dcbcf4d3b654c4897d7d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="168c6b2a6559a30f1500dcbcf4d3b654c4897d7d" Add testcase from trac #1171 as cg059 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:01:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:01:49 -0000 Subject: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs In-Reply-To: <044.8e35f3f081476c88034fdd2fc5fbcf86@haskell.org> References: <044.8e35f3f081476c88034fdd2fc5fbcf86@haskell.org> Message-ID: <059.2929fe2e60f1c96ddbf407d831c344d7@haskell.org> #1196: Cabal on Windows doesn't like the in-place GHCs -----------------------------+--------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: cabal01, cabal02 -----------------------------+--------------------------------- Comment (by Ian Lynagh ): In [changeset:"bb318da85f98a79aef951a6aa3fbf996b75c0007/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bb318da85f98a79aef951a6aa3fbf996b75c0007" cabal01 is broken on Windows; trac #1196 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:04:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:04:26 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.08aa89e2fd27818f41b9b3ebf8987c6a@haskell.org> #8545: Reorganize Git repositories -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: | Keywords: git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8251 -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"5f54d67818ee7a74325eed130438beba96510e43/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5f54d67818ee7a74325eed130438beba96510e43" Update `sync-all` and others files w.r.t. merged testsuite (re #8545) See merge commit 66693401b98cb5aa912948af7bbd2182474f50c4 This commit also adds a check for a left-over testsuite/.git folder to sync-all This way, the first time sync-all is called after updating to a post-testsuite-merge (see #8545) state of ghc.git, the sync-all script aborts with an error message if a `testsuite/.git` folder is detected and thus forces the user to take action. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:13:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:13:35 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.236c72c74c227a79189cc892b8fe6ebd@haskell.org> #8545: Reorganize Git repositories -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: | Keywords: git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8251 -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"66693401b98cb5aa912948af7bbd2182474f50c4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="66693401b98cb5aa912948af7bbd2182474f50c4" Fold testsuite.git into ghc.git (re #8545) This commit performs a subtree merge of testsuite.git into ghc.git; The next commit will adapt `sync-all` et al. to the new situation. At the time of merge, testsuite.git was at commit [998a816ae89c4fd573f4abd7c6abb346cf7ee9af/testsuite] The following steps have been used to accomplish this merge: 1. Clone a fresh testsuite.git copy (& cd into) 2. Remove accidentally committed binary files from history git filter-branch \ --index-filter "git rm -r --cached --ignore-unmatch \ tests/haddock/should_compile_flag_nohaddock/a.out \ tests/haddock/should_compile_noflag_nohaddock/a.out \ tests/ghc-regress/haddock/should_compile_flag_nohaddock/a.out \ tests/ghc-regress/haddock/should_compile_noflag_nohaddock/a.out \ tests/ghc-regress/dph/diophantine/dph-diophantine-fast \ tests/ghc-regress/dph/diophantine/dph-diophantine-opt \ tests/ghc-regress/dph/primespj/dph-primespj-fast \ tests/ghc-regress/dph/quickhull/dph-quickhull-fast \ tests/ghc-regress/dph/smvm/dph-smvm \ tests/ghc-regress/dph/sumnats/dph-sumnats \ tests/ghc-regress/dph/words/dph-words-fast \ tests/ghc-regress/plugins/plugins01" \ HEAD 3. Rename all paths in testsuite.git to be prefixed with `testsuite/` git filter-branch -f --prune-empty --tree-filter \ "mkdir -p testsuite; \ git ls-tree --name-only \$GIT_COMMIT | xargs -I files mv files testsuite/" 4. cd into ghc/ checkout, and perform subtree merge of testsuite into ghc (see also http://nuclearsquid.com/writings/subtree-merging-and-you/) cd ../ghc/ git remote add -f testsuite ../testsuite/.git git merge -s ours --no-commit testsuite/master git read-tree --prefix=/ -u testsuite/master git commit Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:25:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:25:18 -0000 Subject: [GHC] #8590: Reduce code size of CAFs In-Reply-To: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> References: <044.abfe0e6f5cd5b3fe2a2632f41576ec73@haskell.org> Message-ID: <059.6287144e9b06fa43a8c6025821934f48@haskell.org> #8590: Reduce code size of CAFs -------------------------------------+------------------------------------ Reporter: parcs | Owner: parcs Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * cc: miffoljud@? (added) Comment: Hi Patrick, did you make any new progress on your `tmp.diff` patch? Did you create a new ticket for that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:30:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:30:29 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c In-Reply-To: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> References: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> Message-ID: <062.d5333a8ed01db589e672a91d768f7f01@haskell.org> #8646: Distinguish between update frames in rts/Printer.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: feature request | Status: patch Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Hi again, anything I can do to help this getting merged? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:39:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:39:54 -0000 Subject: [GHC] #1371: Add -O3 In-Reply-To: <047.ced6803015445f0338eed48b471b4d41@haskell.org> References: <047.ced6803015445f0338eed48b471b4d41@haskell.org> Message-ID: <062.5de39ed112fae22ceb17bfdeefe8d2da@haskell.org> #1371: Add -O3 ----------------------------+---------------------------------------------- Reporter: | Owner: simonmar | Status: new Type: task | Milestone: _|_ Priority: normal | Version: 6.6.1 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by schyler): I keep seeing people use -O2 -optlo -O3 when using -fllvm. Maybe this is worth taking a look at, if anything, just to bump up some base numbers and increase the llvm optimisation level in a more friendly way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 12:45:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 12:45:50 -0000 Subject: [GHC] #8662: GHC does not inline cheap inner loop when used in two places In-Reply-To: <042.69b3bccc171bc071ffddab8e8b0c335c@haskell.org> References: <042.69b3bccc171bc071ffddab8e8b0c335c@haskell.org> Message-ID: <057.baa3a944fc662010db78306dee85c344@haskell.org> #8662: GHC does not inline cheap inner loop when used in two places --------------------------------------------+------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 schyler): Maybe you just need to tune the numbers higher. Will `-funfolding-use-threshold=16` do it? Maybe this is relevant to #1371 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 13:25:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 13:25:18 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.b30e3b2a23a732d1d0d9cbaee3424438@haskell.org> #8545: Reorganize Git repositories -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: | Keywords: git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8251 -------------------------------------+------------------------------------ Comment (by hvr): Note: While the mail commit notification hook was disabled (and before re- enabling it, the commit-id database updated to contain the new commits), the Trac update hook wasn't from the beginning of the transaction; so about 80 trac updates were performed on ancient tickets (+ mail notifications); this really needs to be taken into account next time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 14:59:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 14:59:43 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.4e86a689cd71cda777e6edceb60af100@haskell.org> #8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by stigge): * cc: stigge@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 15:01:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 15:01:44 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.7a26610f46de35d89ad0ffbf7dfc918f@haskell.org> #8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by stigge): I just tested if reverting the (single) commit aa779e092c4f4d6a6691f3a4fc4074e6359337f8 fixes the issue. But it doesn't. (Trying to cross-compile GHC on powerpc e500v2 / SPE / Debian port powerpcspe.) Any hint how I can help solving this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 15:04:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 15:04:51 -0000 Subject: [GHC] #8662: GHC does not inline cheap inner loop when used in two places In-Reply-To: <042.69b3bccc171bc071ffddab8e8b0c335c@haskell.org> References: <042.69b3bccc171bc071ffddab8e8b0c335c@haskell.org> Message-ID: <057.26e54634d4d0aa928028c44992f3e5a5@haskell.org> #8662: GHC does not inline cheap inner loop when used in two places --------------------------------------------+------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 nh2): Why should it not do this automatically? It is a pretty cheap function (from my human-not-compiler perspective). Why do you need to set such a big threshold to get it inlined? Is there a page that describes how these thresholds work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 17:28:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 17:28:39 -0000 Subject: [GHC] #8665: RELEASE_LOCK: I do not own this lock Message-ID: <044.046fcc75b25880b48183ae432cde742a@haskell.org> #8665: RELEASE_LOCK: I do not own this lock ----------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Got this error running the latest version of Yesod: {{{ Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 devel.hs: internal error: RELEASE_LOCK: I do not own this lock: rts/Capability.c 431 (GHC version 7.6.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Exit code: ExitFailure 6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 20:45:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 20:45:35 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.7a3d113d939e7e57bf5d788a374696bc@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"ae87e122b1bc0f388d43d28fb9fc4886c72ba022/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ae87e122b1bc0f388d43d28fb9fc4886c72ba022" Fix #8180 When compiling a set of modules under --make, we need to check if the module graph has TemplateHaskell enabled. If it does, then we need to switch on -dynamic-too for GHCi, so that the linker can properly find the right dynamic object files. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 20:49:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 20:49:51 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.d0cced1b4dc41a4cad3f5b6f1d6e814d@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): This should now be fixed - with the example above, `ghc Main.hs` should Just Work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 20:49:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 20:49:59 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.d717632906b41eae00c2f20140fe6c8c@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 22:58:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 22:58:11 -0000 Subject: [GHC] #1371: Add -O3 In-Reply-To: <047.ced6803015445f0338eed48b471b4d41@haskell.org> References: <047.ced6803015445f0338eed48b471b4d41@haskell.org> Message-ID: <062.5f7112dca70fc933ca4f966647ed7196@haskell.org> #1371: Add -O3 ----------------------------+---------------------------------------------- Reporter: | Owner: simonmar | Status: new Type: task | Milestone: _|_ Priority: normal | Version: 6.6.1 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by carter): @schyler, who is doing that? -O3 on LLVM's opt has very version specific meaning, and (currently, according to discussions on the llvm-devs mailing list), has much less clear semantics than does -O3 in gcc. Do you have specific examples where llvm's O3 improves ghc code's perf? What LLVM version (please share). its worth noting that generally on LLVM, many optimizations are in O3 to denote experimental / doesn't always work status, and then get promoted ot O1 / O2 when they have more robust code improvement characteristics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 12 23:45:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Jan 2014 23:45:07 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.f89256a7ad1c174f0b79b65d4fa1feec@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:7 hvr]: > Otoh, passing a 0-pointer for the 3-tuple variant has the same danger. > > So now I'm left wondering if I can somehow statically allocate a dummy `ByteArray#` I can return in Cmm when there's no need to allocate a proper `ByteArray#` in order to avoid confusing the GC. I've workarounded this by returning a pointer to one of the statically allocated INTLIKE `Int`s, (which as far as I understand it should correspond to `unsafeCoerce#`ing an `Int` into a `ByteArray#`) which should be somewhat more polite to the garbage collector than coercing a non-pointer `0## :: Word#` into a `ByteArray#`. The latest patch for review with more details in its commit message can be found at [20d7bfdd29917f5a8b8937fba9b724f7e71cd8dd/integer-gmp]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 06:28:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 06:28:13 -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.d574be9aa2d1c083a6f577238f2a1999@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d" Add Windows to NoSharedLibsPlatformList We're punting on full -dynamic and -dynamic-too support for Windows right now, since it's still unstable. Also, ensure "Support dynamic-too" in `ghc --info` is set to "NO" for Cabal. See issues #7134, #8228, and #5987 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 06:28:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 06:28:14 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.0cf71c62ad33a53c38889e075c8a1e0b@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files --------------------------------------------+------------------------------ Reporter: ezyang | Owner: Type: bug | thoughtpolice Priority: highest | Status: new Component: Compiler | Milestone: 7.8.1 Resolution: | Version: 7.7 Operating System: Windows | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: cabal01 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #7134 --------------------------------------------+------------------------------ Comment (by Austin Seipp ): In [changeset:"4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d" Add Windows to NoSharedLibsPlatformList We're punting on full -dynamic and -dynamic-too support for Windows right now, since it's still unstable. Also, ensure "Support dynamic-too" in `ghc --info` is set to "NO" for Cabal. See issues #7134, #8228, and #5987 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 06:28:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 06:28:15 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.3f560444d43d01c08037bbadcebde79a@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d" Add Windows to NoSharedLibsPlatformList We're punting on full -dynamic and -dynamic-too support for Windows right now, since it's still unstable. Also, ensure "Support dynamic-too" in `ghc --info` is set to "NO" for Cabal. See issues #7134, #8228, and #5987 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 08:24:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 08:24:56 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.a186b7f329fdb1523c4f9f45e28925f7@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I think you want to add `-dynamic-too` only if (a) `dyanmicGhc==True` and (b) The `-dynamic` flag is off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 08:25:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 08:25:13 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.2b9c71968f4d73b66459d6230b195e5a@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * owner: thoughtpolice => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 08:34:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 08:34:48 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.82db456bea9aeb54b5ba1366b4d37e10@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Is this build failure a fallout from your changes? https://s3.amazonaws.com/archive.travis-ci.org/jobs/16832833/log.txt Note that I build (to keep the build time low) with {{{ echo 'DYNAMIC_GHC_PROGRAMS = NO' >> mk/build.mk echo 'GhcLibWays = v' >> mk/build.mk }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 08:36:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 08:36:11 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.c678b995aea4eb405889d2f21174ccbc@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Yep, sorry about that. Fix incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 09:01:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 09:01:59 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.4cd6d7f2149c969098c312c2d763979b@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by simonpj): That looks better but would need COPIOUS comments. The ice is thin whenever you use unsafeCoerce. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 09:44:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 09:44:09 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.7c7f07ff86a9912793f21db014de57a9@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): The patches for GHC and Cabal work fine on my machine: {{{ % otool -L ~/.cabal/lib/x86_64-osx- ghc-7.7.20140103/parsec-3.1.5/libHSparsec-3.1.5-ghc7.7.20140103.dylib /Users/christiaan/.cabal/lib/x86_64-osx- ghc-7.7.20140103/parsec-3.1.5/libHSparsec-3.1.5-ghc7.7.20140103.dylib: @rpath/libHSparsec-3.1.5-ghc7.7.20140103.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHStext-1.1.0.0-ghc7.7.20140103.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSmtl-2.1.2-ghc7.7.20140103.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHStransformers-0.3.0.0-ghc7.7.20140103.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSbytestring-0.10.4.0-ghc7.7.20140103.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSdeepseq-1.3.0.2-ghc7.7.20140103.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSarray-0.5.0.0-ghc7.7.20140103.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSbase-4.7.0.0-ghc7.7.20140103.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSinteger-gmp-0.5.1.0-ghc7.7.20140103.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSghc-prim-0.3.1.0-ghc7.7.20140103.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libgmp.10.dylib (compatibility version 12.0.0, current version 12.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 09:45:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 09:45:08 -0000 Subject: [GHC] #8662: GHC does not inline cheap inner loop when used in two places In-Reply-To: <042.69b3bccc171bc071ffddab8e8b0c335c@haskell.org> References: <042.69b3bccc171bc071ffddab8e8b0c335c@haskell.org> Message-ID: <057.537ea47020485993a85d4b6ee66f6d1f@haskell.org> #8662: GHC does not inline cheap inner loop when used in two places --------------------------------------------+------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): GHC decides when to inline like this: * It computes the "size" of the function * At a call site, it takes the size of the function, subtracts a call- site "discount", and if the result is less than the "unfolding threshold" it does the inlining. * The discount is increased if both (a) an actual argument has some structure (eg is a constructor application) and (b) that argument is scrutinised by a case expression in the function body. * There is also a "result discount" if (a) the function call is consumed by a `case`, and (b) the function body returns a constructor application All this is computed in module `CoreUnfold`, so it is nicely separated from the rest of the compiler. Do by all means have a go at changing the computation of size or discount. Then measure (a) the change in code size and complication time vs (b) the change in allocation and/or run-time. If you can reduce (b) without increasing (a) you are winning! But it's easy to mess up. I have spent many happy hours fiddling with these heuristics. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 10:51:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 10:51:37 -0000 Subject: [GHC] #1885: Improve CPR analysis In-Reply-To: <046.6c11df8aecc98c3db1f131fb2c9dc642@haskell.org> References: <046.6c11df8aecc98c3db1f131fb2c9dc642@haskell.org> Message-ID: <061.afc8a83b07d6ebe46afe638ddf23d55e@haskell.org> #1885: Improve CPR analysis -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Just tested this with GHC 7.6.3, and with `-DPOLY_OTHER` it runs really fast. So I guess this can be closed (and looks like it is not related to nested CPR). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 11:04:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 11:04:26 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.3fc0ab0a805aa02d538f06924ac751d5@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): @darchon Can you guess which instruction of mine is wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 11:11:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 11:11:03 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.f3a71caa62438ade27c0af8321a9077d@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): It seems as if you _only_ applied the Cabal patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 11:17:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 11:17:11 -0000 Subject: [GHC] #1885: Improve CPR analysis In-Reply-To: <046.6c11df8aecc98c3db1f131fb2c9dc642@haskell.org> References: <046.6c11df8aecc98c3db1f131fb2c9dc642@haskell.org> Message-ID: <061.03f987b4cd50604792ceb719656d990c@haskell.org> #1885: Improve CPR analysis -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: simonpj => * status: closed => new * resolution: fixed => Comment: Well, it would be good to know WHY it runs really fast. Maybe the function is being inlined... but it it was bigger it wouldn't be, and nested CPR might be just the job. I'd rather know that it was fixed (rather than just have the symptoms disappear) before closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 12:01:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 12:01:56 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze Message-ID: <048.8db85b43ef2d1468096db30170850312@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze -----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Operating System: Linux Keywords: | Type of failure: Compile-time crash Architecture: x86_64 (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I get an error when compiling recent HEAD on Debian Squeeze: {{{ "inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name integer-gmp-0.5.1.0 -hide-all- packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist- install/build -ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist- install/build/autogen -Ilibraries/integer-gmp/. -optP-include -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010 -O -fasm -no-user-package-db -rtsopts -Ilibraries/integer- gmp/mkGmpDerivedConstants/dist -odir libraries/integer-gmp/dist- install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/integer-gmp/dist-install/build -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin libraries/integer-gmp/dist- install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/GMP/Prim.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/Logarithms.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/Logarithms/Internals.dyn_o libraries/integer-gmp /dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist- install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist- install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o -shared -dynamic -dynload deploy -no-auto-link-packages -o libraries /integer-gmp/dist-install/build/libHSinteger- gmp-0.5.1.0-ghc7.7.20140113.so Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_sub' can not be used when making a shared object; recompile with -fPIC libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger- gmp-0.5.1.0-ghc7.7.20140113.so] Error 1 make: *** [all] Error 2 }}} I can build in-tree `libgmp` by extracting it and running `./configure make`. Following Austin's and Herbert's suggestions I tried adding `-fPIC` to command line options but with no result - see attachements. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 12:12:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 12:12:00 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.dc560191e08d145a16380ce60298577c@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): `-XImpredicativeTypes` it not a very well-defined flag. It might make this program compile, and I think it'd be safe to enable it for GND- produced code. But it has had no love for many years. Do give it a try; which would make Q2 moot. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 12:14:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 12:14:31 -0000 Subject: [GHC] #4101: Primitive constant unfolding In-Reply-To: <045.7851f231c35583c6d8f82e7d68f78eb0@haskell.org> References: <045.7851f231c35583c6d8f82e7d68f78eb0@haskell.org> Message-ID: <060.24618c53709387cc079209c64b9df94b@haskell.org> #4101: Primitive constant unfolding --------------------------------------------+--------------------------- Reporter: malosh | Owner: schyler Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+--------------------------- Changes (by schyler): * cc: schyler (added) * difficulty: => Unknown * owner: => schyler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 12:15:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 12:15:19 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.ff9097f1eaa9aa433e301dbb83b4a750@haskell.org> #8566: Given kind equalities are discarded -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Maybe we could reject any data constructor whose type risks an existential kind equality (eg including the type-function thing you mention). That would be conservative but safe. Maybe with a flag to say "ok, drop the check and I'll deal with any bad error messages I get". Would you like to try that? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 12:23:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 12:23:43 -0000 Subject: [GHC] #8616: "Internal error" with ScopedTypeVariables and kind variables In-Reply-To: <047.f65784d6e37be57e3df5d424a2fe4ddd@haskell.org> References: <047.f65784d6e37be57e3df5d424a2fe4ddd@haskell.org> Message-ID: <062.8bd2d73ebd2835efbdfe10e8e3b0f280@haskell.org> #8616: "Internal error" with ScopedTypeVariables and kind variables -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"2d9be8cb1152e78ae2408202663b20bcd9cb8ec2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2d9be8cb1152e78ae2408202663b20bcd9cb8ec2" Test Trac #8616 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 12:24:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 12:24:47 -0000 Subject: [GHC] #8616: "Internal error" with ScopedTypeVariables and kind variables In-Reply-To: <047.f65784d6e37be57e3df5d424a2fe4ddd@haskell.org> References: <047.f65784d6e37be57e3df5d424a2fe4ddd@haskell.org> Message-ID: <062.612197ed5f6b14c77e038ff2437aa63b@haskell.org> #8616: "Internal error" with ScopedTypeVariables and kind variables -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8616 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * testcase: => polykinds/T8616 * resolution: => fixed Comment: Fixed, thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 13:15:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 13:15:50 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.3d2e60b66dc690fbfca4773b835e820b@haskell.org> #8657: -fregs-graph still has a limit on spill slots ---------------------------------------+----------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7679 ---------------------------------------+----------------------------------- Comment (by schyler): Could it be ninja-fixed before 7.8.1? :/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 13:25:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 13:25:24 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.da5655042380049e56ef06f8608c721e@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"7bdcadda7e884edffb1427f0685493f3a2e5c5fa/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="7bdcadda7e884edffb1427f0685493f3a2e5c5fa" Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type We now allocate a 1-limb mpz_t on the stack instead of doing a more expensive heap-allocation (especially if the heap-allocated copy becomes garbage right away); this addresses #8647. In order to delay heap allocations of 1-limb `ByteArray#`s instead of the previous `(# Int#, ByteArray# #)` pair, a 3-tuple `(# Int#, ByteArray#, Word# #)` is returned now. This tuple is given the type-synonym `MPZ#`. This 3-tuple representation uses either the 1st and the 2nd element, or the 1st and the 3rd element to represent the limb(s) (NB: undefined `ByteArray#` elements must not be accessed as they don't point to a proper `ByteArray#`, see also `DUMMY_BYTE_ARR`); more specifically, the following encoding is used (where `?` means undefined/unused): - (# 0#, ?, 0## #) -> value = 0 - (# 1#, ?, w #) -> value = w - (# -1#, ?, w #) -> value = -w - (# s#, d, 0## #) -> value = J# s d The `mpzToInteger` helper takes care of converting `MPZ#` into an `Integer`, and allocating a 1-limb `ByteArray#` in case the value (`w`/`-w`) doesn't fit the `S# Int#` representation). The following nofib benchmarks benefit from this optimization: Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------ bernouilli +0.2% -5.2% 0.12 0.12 +0.0% gamteb +0.2% -1.7% 0.03 0.03 +0.0% kahan +0.3% -13.2% 0.17 0.17 +0.0% mandel +0.2% -24.6% 0.04 0.04 +0.0% power +0.2% -2.6% -2.0% -2.0% -8.3% primetest +0.1% -17.3% 0.06 0.06 +0.0% rsa +0.2% -18.5% 0.02 0.02 +0.0% scs +0.1% -2.9% -0.1% -0.1% +0.0% sphere +0.3% -0.8% 0.03 0.03 +0.0% symalg +0.2% -3.1% 0.01 0.01 +0.0% ------------------------------------------------------------------ Min +0.1% -24.6% -4.6% -4.6% -8.3% Max +0.3% +0.0% +5.9% +5.9% +4.5% Geometric Mean +0.2% -1.0% +0.2% +0.2% -0.0% Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 13:25:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 13:25:38 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.46452c40ed2d29779b4f37f0f7844e12@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"a3616cd624e84d7967257561ad1c80b6793d4b46/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a3616cd624e84d7967257561ad1c80b6793d4b46" Lower T4830/allocated_bytes due to [7bdcadda7/integer-gmp] (#8647) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 14:18:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 14:18:18 -0000 Subject: [GHC] #6070: Fun with the demand analyser In-Reply-To: <046.c6530061559c47a83051d5bf2c366594@haskell.org> References: <046.c6530061559c47a83051d5bf2c366594@haskell.org> Message-ID: <061.acc0afa207c167128ff48055a4277386@haskell.org> #6070: Fun with the demand analyser -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): The first issue is also reported as #5949. So I guess this ticket should track the second infelicity. Unfortunately, I am not able to edit the ticket description, otherwise I?d remove it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 16:35:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 16:35:24 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.289283fc5f90d423d5b3a4d0ef55f4fc@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"cbde86278d2090e19e62f0dd22682b4381433658/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="cbde86278d2090e19e62f0dd22682b4381433658" Wrap `gmpz_fdiv_{q,r,qr}_ui` to optimize `div`/`mod` This is similiar to what has been done in [af2ba9c8/integer-gmp] for `gmpz_tdiv_{q,r,qr}_ui` (re #8647); However, the gain is more modest here, as performance-conscious code tends to use `quot`/`rem` rather than `div`/`mod`: Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------- primetest +0.3% -2.4% 0.06 0.06 +0.0% rsa +0.2% -3.3% 0.02 0.02 +0.0% Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 16:35:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 16:35:37 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.85b64abb89b76e75a6af0d27f3808e99@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"8a0f1d2f8336cf6c63d32b76f22df8ee4407f19e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8a0f1d2f8336cf6c63d32b76f22df8ee4407f19e" Adapt perf values due to [cbde8627/integer-gmp] These are slight improvements due to optimizations in `integer-gmp` (#8647) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 16:38:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 16:38:15 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.e77e733be8252179aa2bdfc818a946e2@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Looking into Q1. There is some code temporarily enabling certain extension (`EmptyCase`, `ScopedTypeVariables` and `KindSignatures`) in `renameDeriv`, but these just affect the renamer; the error message we see occurs later, and I don?t see how we can enable `ImpredicativeTypes` in a scoped way, i.e. only applying to the code generated by GND. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 17:01:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 17:01:04 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.cad7ccc5cb265fdd3b77af0f77cc91b7@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): New numbers, after uprooting a bug where things unrelated to CPR (namely things alrady returning an unboxed tuple, with nothing to be CPRed inside) would suddenly get an `INLINE` flag, including some thunks. Finally a measurable positive change in the geometric mean! {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi +0.3% -0.1% 0.00 0.00 +0.0% awards +0.3% -0.1% 0.00 0.00 +0.0% compress2 +0.5% -0.8% 0.11 0.11 -8.0% fibheaps +0.3% -0.3% 0.03 0.03 +0.0% gamteb +0.3% -0.2% 0.04 0.04 +0.0% grep +0.3% -0.1% 0.00 0.00 +0.0% hpg +0.3% -3.0% 0.13 0.13 +0.0% infer +0.3% -1.2% 0.04 0.04 +0.0% k-nucleotide +0.1% -6.9% -1.3% -1.1% +0.0% kahan -11.9% -0.1% 0.17 0.17 +0.0% maillist +0.3% -0.8% 0.04 0.04 -22.5% mkhprog +0.3% -0.3% 0.00 0.00 +0.0% pic +0.3% -0.6% 0.00 0.00 +0.0% pretty +0.3% -0.1% 0.00 0.00 +0.0% rfib +0.3% -0.1% 0.01 0.01 +0.0% scc +0.3% -0.1% 0.00 0.00 +0.0% spectral-norm +0.3% -0.1% +0.2% +0.3% +0.0% sphere +0.3% -4.7% 0.04 0.04 +0.0% symalg +0.3% -0.1% 0.01 0.01 +0.0% tak +0.3% -0.3% 0.01 0.01 +0.0% transform +0.3% +0.2% -0.7% -0.7% +0.0% wave4main +0.4% +12.2% 0.21 0.21 +7.7% -------------------------------------------------------------------------------- Min -11.9% -6.9% -4.5% -26.8% -22.5% Max +0.6% +12.2% +2.1% +1.9% +50.0% Geometric Mean +0.2% -0.1% -0.3% -2.1% +0.1% }}} The increase of `wave4main` is due to a lost join point, as discussed in [wiki:NestedCPR/wave4main]. The increase in transform is not yet investigated (but will be, and then be discussed [wiki:NestedCPR#Motivatingexamples here]. I also did not look into the code size changes yet; `kahan` certainly looks interesting here... I was not especially careful about the runtime numbers, but I believe that the machine was unloaded when doing either ran. It certainly was when I was doing the baseline. So these are maybe a bit reliable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 17:38:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 17:38:16 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.0a0d1f4aa9eea0d11efa81a97fed4c11@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): New numbers, after uprooting a bug where things unrelated to CPR (namely things alrady returning an unboxed tuple, with nothing to be CPRed inside) would suddenly get an `INLINE` flag, including some thunks. Finally a measurable positive change in the geometric mean! {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi +0.3% -0.1% 0.00 0.00 +0.0% compress2 +0.6% -0.8% 0.11 0.11 -8.0% fibheaps +0.3% -0.3% 0.03 0.03 +0.0% gamteb +0.4% -0.2% 0.04 0.04 +0.0% grep +0.3% -0.1% 0.00 0.00 +0.0% hpg +0.4% -3.0% 0.13 0.13 +0.0% infer +0.3% -1.2% 0.03 0.03 +0.0% k-nucleotide +0.2% -6.9% -1.6% -1.4% +0.0% maillist +0.4% -0.8% 0.04 0.04 +0.8% mkhprog +0.4% -0.3% 0.00 0.00 +0.0% pic +0.3% -0.7% 0.00 0.00 +0.0% pretty +0.4% -0.1% 0.00 0.00 +0.0% rfib +0.3% -0.2% 0.01 0.01 +0.0% scc +0.3% -0.1% 0.00 0.00 +0.0% spectral-norm +0.4% -0.1% +0.3% +0.3% +0.0% sphere +0.4% -4.7% 0.04 0.04 +0.0% symalg +0.3% -0.1% 0.01 0.01 +0.0% tak +0.3% -0.3% 0.01 0.01 +0.0% transform +0.3% +0.2% -2.2% -2.2% +0.0% -------------------------------------------------------------------------------- Min +0.2% -6.9% -5.3% -28.2% -11.2% Max +0.7% +0.2% +2.1% +2.1% +50.0% Geometric Mean +0.3% -0.2% -0.8% -2.3% +0.2% }}} Surprisingly to me, the bug fix also fixed a +11% increase in wave4main?s allocations, which I thought were caused by join-point losses. A quick glance into `transform` shows that `f_list_cmp` lost its (non- nested) CPR property, accounting for most of the increase according to ticky. Will investigate tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 17:43:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 17:43:04 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.6aa82c5e95c980f9da0d4a979c50a7c5@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: => thoughtpolice Comment: If you can?t fix a broken test right away, please consider marking them as `known_broken`. It reduces confusion for other developers and keeps CI tools useful. (Reopening so that this is not forgotten.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 19:09:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 19:09:40 -0000 Subject: [GHC] #4101: Primitive constant unfolding In-Reply-To: <045.7851f231c35583c6d8f82e7d68f78eb0@haskell.org> References: <045.7851f231c35583c6d8f82e7d68f78eb0@haskell.org> Message-ID: <060.2258c99a0b93757c038c25fcf53be545@haskell.org> #4101: Primitive constant unfolding --------------------------------------------+--------------------------- Reporter: malosh | Owner: schyler Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): @schyler please please be very careful about anything regarding evaluating floating point, I think before we add optimizations and constant propagation for floating point computations we really need to enrich GHC's internal data model of floating point. a Naive constant progagation alg will not be correct for floating point. I'd in fact argue that any constant propagtion stuff first needs that internal model cleaned up first to be correct. Relatedly: many floating point libs do a lot of work that exploits the specific structure of floating point, for example edward kmett's compensated lib http://hackage.haskell.org/package/compensated I think the first step would be adding better support for writing double# and float# literals, perhaps with hexadecimal notation support, as this ticket suggests, as a prereq to the subsequent parts of the ticket. Perhaps that literal support should be spun out into its own ticket and your first task is adding that literals support? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 19:44:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 19:44:02 -0000 Subject: [GHC] #4101: Primitive constant unfolding In-Reply-To: <045.7851f231c35583c6d8f82e7d68f78eb0@haskell.org> References: <045.7851f231c35583c6d8f82e7d68f78eb0@haskell.org> Message-ID: <060.3922df1ed8371466dc137d32d5fd9dcd@haskell.org> #4101: Primitive constant unfolding --------------------------------------------+--------------------------- Reporter: malosh | Owner: schyler Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+--------------------------- Comment (by carter): So one thing that also maybe needs to be done is add proper way of tracking NAN and other exception values (and coding them correctly too) as a prereq for constant evaluation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 21:47:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 21:47:17 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.11574051cd9012f59b8939b2dbc59ab0@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by yoeight): Replying to [comment:9 goldfire]: > This looks nice -- I can easily believe it works. Here is some feedback I have on the code: > > * I would want to see this handle `IrredPred` predicates, as well as tuples. That way, synonyms built with !ConstraintKinds would be fully supported by TH. I don't think this should be too much work beyond what you've already done. Do you have any pointer on what irreducible predicates are please ? If it's possible, could you provide a code sample that triggers irreducible predicate TH error ? > > * I still think a change to !DsMeta is warranted. For example, I would imagine code like `[t| (Show a, (Read a, Num a)) => a -> a |]` would fail to compile, even though TH would now be able to represent such a predicate. You were right, I got an error when compiling your code. I think we should use it in a new test case in order to increase code coverage. What do you think ? > > * The functions `classP` and `equalP` in the `Lib` module are meant to echo the constructors of `Pred`. I would say that, now that `Pred` is a synonym, `classP` and `equalP` should be removed. (It took me a while to understand why all those functions are there in `Lib` -- the answer is that !DsMeta is ''much'' easier to write with those functions there.) Leaving `classP` and `equalP` doesn't cause anyone any real harm, but it would just be a small wart on the design that could easily be eliminated. > > * Along similar lines, you will probably find that you need an `equalityT` function in `Lib` when updating !DsMeta. > > * It looks like you left the old `Pred` commented-out in `Syntax`. > > * While it is probably too late now (and I don't think worth going back to fix), it's best to do whitespace changes in separate commits from substantive changes. Perhaps before editing a new file, removing the trailing whitespace, make a commit, and then go back and to the real changes. You can always then rebase at the end of your session to lump together all the whitespace commits. > I agree. The thing is, I have `(add-to-list 'write-file-functions 'delete- trailing-whitespace)` in my `.emacs`. I didn't notice until I posted my patches. > Continued thanks for working on this! Thanks for your feedback ! Yorick -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 23:36:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 23:36:46 -0000 Subject: [GHC] #8667: sync-all doesn't work properly if you run from a fork on github Message-ID: <046.9085bad8b794dc6ebf21080eed03b8f6@haskell.org> #8667: sync-all doesn't work properly if you run from a fork on github ------------------------------------+------------------------------------- Reporter: schyler | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The intuitive behaviour when working with projects on github is to make your own fork so that you can use the online interface (or GitHub for {windows,osx} apps). One would assume that this behaviour was endorsed because of the ~130 forks to the ghc repo, however forking the repo actually causes ./sync-all to stop working (it asks for a username and password to whomever@ github.com). It seems the only way for a person to work with the project from github is to clone directly from the original repo. This sounds like a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 13 23:48:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Jan 2014 23:48:47 -0000 Subject: [GHC] #8667: sync-all doesn't work properly if you run from a fork on github In-Reply-To: <046.9085bad8b794dc6ebf21080eed03b8f6@haskell.org> References: <046.9085bad8b794dc6ebf21080eed03b8f6@haskell.org> Message-ID: <061.78bd805c0a975582189053df12f36153@haskell.org> #8667: sync-all doesn't work properly if you run from a fork on github -------------------------------------+------------------------------------ Reporter: schyler | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by schyler): Steps to reproduce: - fork - clone - attempt to run ./sync-all get -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 00:52:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 00:52:34 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.1cf507930ad6579e806b0385e499ee2b@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Bah. I was thinking of exactly that code when I suggested enabling `ImpredicativeTypes`, but I didn't look closely before making the suggestion. I'll see if I can take a look later this week and come up with an implementation plan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 03:32:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 03:32:08 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.5cb9623c100a98729d84f5ab02033df2@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): The classification of predicates is done by `classifyPredType`, in the Type module. From the definition of that function, any predicate not headed by a class, equality predicate, or tuple is "irreducible". Examples of these include predicates headed by type families or predicates headed by variables. Both of these possibilities require `ConstraintKinds`. Here is a full program that exhibits the problem: {{{ {-# LANGUAGE TemplateHaskell, PolyKinds, ConstraintKinds #-} module Irred where import Language.Haskell.TH data Proxy a = Proxy foo :: a b => Proxy a -> b foo = undefined $( do info <- reify 'foo reportWarning (show info) return [] ) }}} GHC 7.6.3 reports {{{ Can't represent irreducible predicates in Template Haskell: a b }}} Producing this error was admittedly harder than I thought. It turns out that !TcSplice and !DsMeta take rather different routes to translating into the TH syntax. (This is, of course, because !TcSplice is translating from Core while !DsMeta is translating from Haskell.) Only !TcSplice checks the classification of predicates. Using a TH quote with an "irreducible" predicate produces a `ClassP`, even on a type like `foo`'s type, above. I hope this helps! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 03:35:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 03:35:57 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply Message-ID: <047.7bfae31244c263823ac3d1193001c490@haskell.org> #8668: SPECIALIZE silently fails to apply ----------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I have a small example where GHC refuses to specialize a call to `(+)`, compiling with -O2. The two files are Foo.hs (http://lpaste.net/98464) and Main.hs (http://lpaste.net/98342). There seem to be two problems: 1. The active `SPECIALIZE` pragma should be applied, but isn't. This can be seen by comparing the core and runtimes of `fcTest` (slow) vs `vtTest` (fast). I need this version of the pragma in my real code as the phantom type `m` is reified, so I need to specialize the vector code without specifying the phantom type. 2. I can get `fcTest` to run fast if I use the commented-out `SPECIALIZE` pragma instead. However, that pragma seems very straightforward to me (all types are concrete). The docs indicate that GHC should automatically specialize in most cases, why does it not specialize to the commented-out signature automatically? This problem is also posted here: http://stackoverflow.com/questions/21071706/specialization-with- constraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 03:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 03:56:56 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.b87ead374d515aae8f1d2fe9a4aa25ec@haskell.org> #8566: Given kind equalities are discarded -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I'm fine with your last suggestion, but I wonder if there's a different way: instead of rejecting the constructor, what if the "bad error messages" suggest the nature of the problem? For example, if a type error occurs after dropping an unusable given kind equality, that error message could say what kind equality was dropped and why. (This is somewhat like error messages that warn about ambiguous variables.) I would imagine that the folks who write the weirdly-existential constructors would be able to understand such a message and respond appropriately. Would this be an engineering challenge (that is, remembering the dropped given equality, just for error reporting)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 08:02:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 08:02:49 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.58a0ef42ee992f2b45e0158be2d797db@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): I made another try. I applied your patch to Cabal-1.18.1.1 and built cabal-install 1.18.0.2 with GHC 7.6.3. I used the cabal-install again with GHC head but the result is the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 09:45:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 09:45:04 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.2fb0c6a0850d5a2213f23fa244058dc2@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Fixed the `transform` issue (when analysing a complex case expression where we do the scrunitee first to feed nested CPR information into the pattern match variable, I was not making sure that the case binder gets at least a flat CPR property, even if the scrunitee has none), and we are finally where Simon expected nested CPR to be: No increased allocations any more (or at least none that are not surpassed by the gains). Still a very small effect, though. {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ansi +0.3% -0.1% 0.00 0.00 +0.0% awards +0.3% -0.1% 0.00 0.00 +0.0% compress2 +0.6% -0.8% 0.11 0.11 -8.0% fibheaps +0.3% -0.3% 0.03 0.03 +0.0% gamteb +0.4% -0.2% 0.04 0.04 +0.0% grep +0.3% -0.1% 0.00 0.00 +0.0% hpg +0.4% -3.0% 0.13 0.13 +0.0% infer +0.3% -1.2% 0.03 0.03 +0.0% k-nucleotide +0.2% -6.9% -0.7% -0.5% +0.0% maillist +0.4% -0.8% 0.04 0.04 -4.2% mkhprog +0.4% -0.3% 0.00 0.00 +0.0% pic +0.3% -0.7% 0.00 0.00 +0.0% pretty +0.4% -0.1% 0.00 0.00 +0.0% rfib +0.3% -0.2% 0.01 0.01 +0.0% scc +0.3% -0.1% 0.00 0.00 +0.0% spectral-norm +0.4% -0.1% +0.0% +0.0% +0.0% sphere +0.4% -4.7% 0.04 0.04 +0.0% symalg +0.3% -0.1% 0.01 0.01 +0.0% tak +0.3% -0.3% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min +0.2% -6.9% -5.3% -27.3% -8.0% Max +0.7% +0.0% +1.4% +1.4% +50.0% Geometric Mean +0.3% -0.2% -0.7% -2.3% +0.2% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 09:46:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 09:46:36 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.325460f91c18bd3af820c895b24348e1@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"7df27d52cffa915886b9f2860e961a0e7bb5dd1e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7df27d52cffa915886b9f2860e961a0e7bb5dd1e" Fix the behavior of ae87e122 (#8180) As Simon pointed out, we should only enable -dynamic-too in the template haskell case if GHC is dynamic and we're not already compiling in the dyn way (the dyn way will be switched on by -dynamic-too later in the pipeline anyway - see pipeLoop) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 09:49:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 09:49:29 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.75da7815c22cf659e30d5dc1f580b670@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"d2e957dac5738cc694e2c6cab7f56c2b486ed1a4/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="d2e957dac5738cc694e2c6cab7f56c2b486ed1a4" Fix in-tree GMP build (#8497) on OS X Mavericks Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 09:51:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 09:51:01 -0000 Subject: [GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks In-Reply-To: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> References: <052.a945a4fdb4d0e9bf62bd4d9ed8afe8eb@haskell.org> Message-ID: <067.17cc4682c0435d2f8989251a53e3cc96@haskell.org> #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: clang Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: I used Homebrew to install a 64bit GMP, tested that built on Mavericks, then uninstalled it and applied your patch, and the in-tree build worked fine too. Merged - thank you Kazu! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 10:35:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 10:35:09 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.ec63fb26a6b1d8c63f8d7473419de531@haskell.org> #8566: Given kind equalities are discarded -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): That sounds difficult. We can emit a warning when dropping a given kind equality; indeed, my proposal amounts to ensuring that no such warnings would be generated. But to warn only if we drop a kind equality ''that would (later) be needed to make the program type check'' would be a lot harder. I suppose we could keep the kind-equality and complain only if it was used. But being "used" is different to being "needed". Since you want to add full-on kind equalities, we should not over invest in this... let's just do something simple. (Or even nothing.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 11:47:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 11:47:05 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.44c8d7d4f857840dc98ee5ba0db1a8e2@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: This should now be fixed properly. Joachim, I checked your build here and I think it looks good: https://travis-ci.org/nomeata/ghc-complete/builds/16922297 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 13:50:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 13:50:43 -0000 Subject: [GHC] #8669: Closed TypeFamilies regression Message-ID: <045.0e6aecd5851530b4d34897be005ddbd6@haskell.org> #8669: Closed TypeFamilies regression --------------------------+------------------------------------------------ Reporter: merijn | Owner: Type: bug | Status: new Priority: high | Milestone: Component: | Version: 7.7 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I first played around with closed typefamilies early 2013 and wrote up the following simple example {{{ {-# LANGUAGE ConstraintKinds, DataKinds, PolyKinds, TypeFamilies, TypeOperators #-} import GHC.Prim (Constraint) type family Restrict (a :: k) (as :: [k]) :: Constraint type instance where Restrict a (a ': as) = (a ~ "Oops! Tried to apply a restricted type!") Restrict x (a ': as) = Restrict x as Restrict x '[] = () foo :: Restrict a '[(), Int] => a -> a foo = id }}} This worked fine, functioning like `id` for types other than `()` and `Int` and returning a type error for `()` and `Int`. After hearing comments that my example broke when the closed type families syntax changed I decided to update my version of 7.7 and change the code for that. The new code is: {{{ {-# LANGUAGE ConstraintKinds, DataKinds, PolyKinds, TypeFamilies, TypeOperators #-} import GHC.Prim (Constraint) type family Restrict (a :: k) (as :: [k]) :: Constraint where Restrict a (a ': as) = (a ~ "Oops! Tried to apply a restricted type!") Restrict x (a ': as) = Restrict x as Restrict x '[] = () foo :: Restrict a '[(), Int] => a -> a foo = id }}} This code is accepted by the compiler just fine, but the `Constraint` gets thrown out. When querying ghci for the type of `foo` the following is returned: {{{ ? :t foo foo :: a -> a ? :i foo foo :: (Restrict a '[(), Int]) => a -> a }}} Additionally, in the recent 7.7 `foo ()` returns `()` rather than a type error. After some playing around this seems to be caused by the "(a ~ "Oops! Tried to apply a restricted type!")" equality constraint. It seems GHC decides that it doesn't like the fact that types with a polymorphic kind and `Symbol` kind are compared. Leading it to silently discard the `Constraint`. This raises two issues: 1) This should probably produce an error, rather than silently discarding the `Constraint` 2) A better way to produce errors in type families is needed, personally I would love an "error" `Constraint` that takes a `String`/`Symbol` and never holds, producing it's argument `String` as type error (This would remove the need for the hacky unification with `Symbol` to get a somewhat relevant type error). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 14:21:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 14:21:42 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.6efd381ed869d965949c6c82a3815653@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Bummer. While finding out what happened to `wave4main`, I noticed that I introduced a bug (well, imprecision) where `Converges` information was lost. This prevented nested CPR in `wave4main`, and everything looked good. Fixing that bug gives us back the +11.3% for `wave4main`, and also a +0.2% for `scs`. So it remains all very heuristical... The change in `scs` is hard to pin-point, as there is quite a bit of CPR?ing going on which moves allocations between different ticky-ticky- counters. But in the summary, we see an increase in `ALLOC_FUN_gds` again, and there are `$wgo` popping up where there were none, so this indicates lost join points. (Also interesting: `ALLOC_CON_ctr` goes up, but `ALLOC_CON_gds` goes down.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 14:25:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 14:25:47 -0000 Subject: [GHC] #8669: Closed TypeFamilies regression In-Reply-To: <045.0e6aecd5851530b4d34897be005ddbd6@haskell.org> References: <045.0e6aecd5851530b4d34897be005ddbd6@haskell.org> Message-ID: <060.38311903720816ca90cc2c22c3d28c36@haskell.org> #8669: Closed TypeFamilies regression ------------------------------------------------+-------------------------- Reporter: merijn | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonpj): I know why this happens. If I add the kinds to the definition, I get this: {{{ type family Restrict k (a :: k) (as :: [k]) :: Constraint where Restrict Symbol (a::Symbol) (a ': as) = (a ~ "Oops! Tried to apply a restricted type!") Restrict k (x::k) (a ': as) = Restrict x as Restrict k (x::k) '[] = () }}} The first equation only applies to types of kind `Symbol` because the RHS has an equality that forces `a :: Symbol` since `"Oops" :: Symbol`. The constraint `(Restricted (a:*) [(),Int])` can't match the first equation (because the first equation matches only things of kind `Symbol`, so it correctly chooses the second. What to do? For your (2) how about this: {{{ class Error (s::Symbol) -- No instances }}} Now `Error :: Symbol -> Constraint`, as you wanted, and you can write {{{ type instance where Restrict a (a ': as) = Error "Oops! Tried to apply a restricted type!" Restrict x (a ': as) = Restrict x as Restrict x '[] = () }}} And away you go. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 14:31:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 14:31:04 -0000 Subject: [GHC] #8669: Closed TypeFamilies regression In-Reply-To: <045.0e6aecd5851530b4d34897be005ddbd6@haskell.org> References: <045.0e6aecd5851530b4d34897be005ddbd6@haskell.org> Message-ID: <060.c2264e51fe27803cbe49ac585f176064@haskell.org> #8669: Closed TypeFamilies regression ------------------------------------------------+-------------------------- Reporter: merijn | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: (Written before Simon's post -- I guess we think alike!) I would say that GHC's behavior in this case is correct, for the following reasons: 1. The equality operator `~` is ''homogeneous''. This means that the kinds of the types on both sides must be the same. With this in mind, here is `Restrict`, with all kind variables/arguments made explicit: {{{ type family Restrict (k :: BOX) (a :: k) (as :: [k]) :: Constraint where forall (a :: Symbol) (as :: [Symbol]). Restrict Symbol a (a ': as) = (a ~ "...") forall (k :: BOX) (x :: k) (a :: k) (as :: [k]). Restrict k x (a ': as) = Restrict k x as forall (k :: BOX) (x :: k). Restrict k x ('[] k) = () }}} In your `foo`, the variable `a` surely has kind `*`, not `Symbol`. So, the first equation of `Restrict` does not apply, and GHC correctly reduces the type family away when reporting the type of `foo`, as the constraint always reduces to `()`. 2. You suggest that GHC should produce an error here. But, there's no real way for GHC to know that you're not trying to write a ''kind-indexed'' type family, where matching on the kind really is intentional. Some possible ways forward: 1. Closed type families do full kind inference (unlike open ones), but with a twist: a kind variable used in matching must be declared in a kind annotation. Thus, if you use kind inference only, then you indeed would get an error with a definition like `Restrict`. So, unless you want a kind-indexed type family, you might be best off omitting the kind annotations. (I realize there's a good deal of value in having a kind annotation even if you don't want a kind-indexed type family, but putting in the kind variable opens you up to the possibility of silent unintended behavior in this way. I'm open to suggestions of other ways of distinguishing kind-indexed from non-kind-indexed type families!) 2. With or without kind annotations, you can do something like this: {{{ class False ~ True => Error (x :: Symbol) }}} and then use that in your first equation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 14:39:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 14:39:09 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.48060fa30ce0fccf146b225068066b39@haskell.org> #8566: Given kind equalities are discarded -------------------------------------+------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T8566 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I have to say I like your very last proposal best: do nothing. I wouldn't describe the current wonky behavior as wrong, just perhaps seemingly incomplete. If "doing nothing" makes you queasy, I would just put in the warning, though I'm also fine with blocking the constructor definitions as long as there's a way to unblock them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 15:18:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 15:18:58 -0000 Subject: [GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm In-Reply-To: <052.22eb4f882263987206e929bacae5db28@haskell.org> References: <052.22eb4f882263987206e929bacae5db28@haskell.org> Message-ID: <067.7503c5e1f03b767a254e930e84092cb2@haskell.org> #8131: T7571 with WAY=llvm fails, but not WAY=optllvm ----------------------------------------------+---------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: Priority: high | infoneeded Component: Compiler | Milestone: Resolution: | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: llvm/should_compile/T8131 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by thoughtpolice): * status: patch => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 15:21:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 15:21:28 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c In-Reply-To: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> References: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> Message-ID: <062.82a35d5c33969858df4e844737c31bb6@haskell.org> #8646: Distinguish between update frames in rts/Printer.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: thoughtpolice Type: feature request | Status: patch Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * owner: simonmar => thoughtpolice Comment: Ok, approved. I think I'll change the output slightly once it's in, but we can push it in for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 15:21:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 15:21:38 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c In-Reply-To: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> References: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> Message-ID: <062.a73d20eedce9fe218d5f392660d568d7@haskell.org> #8646: Distinguish between update frames in rts/Printer.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * owner: thoughtpolice => * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 17:34:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 17:34:32 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.1d4f6567c31c9aa5768b73ab7316e613@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by duncan): I have to say this makes me very nervous. Cabal does not currently support relocatable packages at all, and a little patch like this is not enough to make it do so. There were at the time good reasons to specify the final install location and so we will need to see if those reasons are no longer valid (e.g. OSX linker features have improved and no longer need to support older OSX releases). Am I correct in thinking that this only affects people using ghc inplace in the build tree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 20:15:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 20:15:53 -0000 Subject: [GHC] #8670: GHC fails to build on Solaris 11 Message-ID: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> #8670: GHC fails to build on Solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Keywords: Cabal | Operating System: Solaris Architecture: x86 | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Hello, GHC HEAD fails to build on Solaris 11, the compilation fails in libraries/haskeline with: {{{ "inplace/bin/hsc2hs" '--cc=/usr/bin/gcc' '--ld=/usr/bin/gcc' --cross-safe -I/opt/gmp-5.1.3/include/ --cflag=-U__i686 --cflag=-fno-stack-protector --cflag=-Di386_HOST_ARCH=1 --cflag=-Dsolaris2_HOST_OS=1 --cflag=-D__GLASGOW_HASKELL__=707 '--cflag=-U__i686' '--cflag=-fno-stack- protector' '--cflag=-Ilibraries/haskeline/includes' '-- cflag=-DUSE_GHC_ENCODINGS' '--cflag=-DTERMINFO' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/directory/include' '--cflag=-I/export/home/karel/vcs/ghc- src/ghc-sol-test/libraries/unix/include' '--cflag=-I/export/home/karel/vcs /ghc-src/ghc-sol-test/libraries/time/include' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/containers/include' '--cflag=-I/export/home/karel/vcs/ghc- src/ghc-sol-test/libraries/bytestring/include' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/base/include' '--cflag=-I/opt/gmp-5.1.3/include/' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol-test/rts/dist/build' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol-test/includes' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol-test/includes/dist- derivedconstants/header' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc- sol-test/libraries/transformers/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/terminfo /dist-install/build' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/directory/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/unix/dist- install/build' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/time/dist-install/build' '--lflag=-L/export/home/karel/vcs /ghc-src/ghc-sol-test/libraries/old-locale/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/filepath /dist-install/build' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/containers/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/bytestring /dist-install/build' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/deepseq/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/array/dist- install/build' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/base/dist-install/build' '--lflag=-L/export/home/karel/vcs /ghc-src/ghc-sol-test/libraries/integer-gmp/dist-install/build' '-- lflag=-L/opt/gmp-5.1.3/lib/' '--lflag=-L/export/home/karel/vcs/ghc-src /ghc-sol-test/libraries/ghc-prim/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/rts/dist/build' '-- lflag=-lcurses' '--lflag=-ldl' '--lflag=-lgmp' '--lflag=-lm' '-- lflag=-lrt' '--lflag=-ldl' --cflag=-Ilibraries/haskeline/dist- install/build/autogen --cflag=-include --cflag=libraries/haskeline/dist- install/build/autogen/cabal_macros.h libraries/haskeline/./System/Console/Haskeline/Backend/Posix.hsc -o libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix.hs Posix.hsc: In function ?main?: Posix.hsc:74:5: error: invalid application of ?sizeof? to incomplete type ?struct winsize? Posix.hsc:76:5: error: ?TIOCGWINSZ? undeclared (first use in this function) Posix.hsc:76:5: note: each undeclared identifier is reported only once for each function it appears in Posix.hsc:77:5: error: invalid use of undefined type ?struct winsize? Posix.hsc:78:5: error: invalid use of undefined type ?struct winsize? compiling libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix_hsc_make.c failed (exit code 1) command was: /usr/bin/gcc -c libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix_hsc_make.c -o libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix_hsc_make.o -I/opt/gmp-5.1.3/include/ -U__i686 -fno-stack-protector -Di386_HOST_ARCH=1 -Dsolaris2_HOST_OS=1 -D__GLASGOW_HASKELL__=707 -U__i686 -fno-stack- protector -Ilibraries/haskeline/includes -DUSE_GHC_ENCODINGS -DTERMINFO -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/directory/include -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/unix/include -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/time/include -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/containers/include -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/bytestring/include -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/base/include -I/opt/gmp-5.1.3/include/ -I/export/home/karel/vcs/ghc-src/ghc-sol- test/rts/dist/build -I/export/home/karel/vcs/ghc-src/ghc-sol-test/includes -I/export/home/karel/vcs/ghc-src/ghc-sol-test/includes/dist- derivedconstants/header -Ilibraries/haskeline/dist-install/build/autogen -include libraries/haskeline/dist-install/build/autogen/cabal_macros.h -I/export/home/karel/vcs/ghc-src/ghc-sol-test/inplace/lib/include/ gmake[1]: *** [libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix.hs] Error 1 }}} The reason for this can be tracked to the haskeline.cabal file code: {{{ if os(solaris) { cpp-options: -DUSE_TERMIOS_H } }}} the cpp-options are not modified on Solaris although they should. The reason for this is a bug in Cabal which does not recognize Solaris from its i386-pc-solaris2.11 triple. The bug is reported with suggested patch here: https://github.com/haskell/cabal/issues/1641 The a little extended patch is already in Cabal HEAD and it is promised to be merged into 1.18 branch by Mikhail Glushenkov here: http://www.haskell.org/pipermail/ghc-devs/2014-January/003819.html Now, the question is if it is possible to get the fix into GHC HEAD before 7.8 RC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 20:39:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 20:39:06 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.563e3a0f4f306714508668b12c8362f1@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): I guess I should have articulated better that the patch for Cabal is _not_ needed for everything to work. The reason for the Cabal patch is simply: * Uniformity between `install_name`s of dynamic libraries supplied by GHC and those installed with Cabal. The new GHC patch adds an `LC_RPATH` command for every dependent library, pointing to the directory that the dependent library is installed in. So if a library is linked against, e.g., `@rpath/libHSbase-4.7.0.0-ghc7.7.20140103.dylib`, it gets an `LC_RPATH` command that points to e.g. `/usr/local/ghc/lib/base-4.7.0.0/`. Now, _without_ the patch to Cabal, a library like `text` would get an `install_name` of `/Users/darchon/.cabal/lib/x86_64-osx- ghc-7.7.20140101/text-1.1.0.0/libHStext-1.1.0.0-ghc7.7.20140103.dylib`. Under the new patch, a library like `parsec` would be linked against `/Users/darchon/.cabal/lib/x86_64-osx- ghc-7.7.20140101/text-1.1.0.0/libHStext-1.1.0.0-ghc7.7.20140103.dylib`, but GHC would still add an `LC_RPATH` pointing to: `/Users/darchon/.cabal/lib/x86_64-osx-ghc-7.7.20140101/text-1.1.0.0`. Of course this `LC_RPATH` command is superfluous/bogus, as there isn't be any `@rpath` referenced dynamic library to be found there. I believe these superfluous `LC_PATH`s to be harmless though. Note that neither the GHC patch nor the Cabal patch intended to make packages/libraries relocatable. It essentially traded one direct/full path for another. In the pre-patch situation the `install_name` is a direct path, in the post-patch situation a library has an `LC_RPATH` that is a direct/full path. So, to sum up: * The new GHC patch solves the original issue of having the GHC build-dir referenced in built/distributed libraries, while also supporting the use- case of building/installing packages using `cabal-install` and the `inplace/bin/ghc-stage2`. * The Cabal patch only add uniformity between `install_names`, but is not necessary for a correctly working GHC/Cabal system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 20:58:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 20:58:57 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.e9b369a5d9b893b0995ce20082578b8e@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): so am I correct in thinking that this issue only matters when someone is building ghc from source and using it without installing it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 21:17:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 21:17:25 -0000 Subject: [GHC] #8670: GHC fails to build on Solaris 11 In-Reply-To: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> References: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> Message-ID: <061.9c0674c0119ed7ec3714ec5597928545@haskell.org> #8670: GHC fails to build on Solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Keywords: Cabal Resolution: | Architecture: x86 Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by hvr): Is this the only thing needed for fixing solaris? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 21:18:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 21:18:26 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.d268f3c7489aa348367b98cff5969de3@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): Could you elaborate 'this issue'? Do you mean, does the current situation (with my previous patch, f213e48447050bf468bc4d91fc4d810402c23b85/ghc, already committed) result in a non-working GHC install for 'normal' users? The answer to that would be _no_, the current situation is just fine for the largest part of the user- base of GHC. If you mean, that you cannot properly use `inplace/bin/ghc-stage2` in combination with `cabal-install`, which matters to both GHC developers/hackers and those wanting bleeding-edge GHC? Then the answer would be _yes_, the way dynamic libraries are set up with my previous patch do not work well with `cabal -w inplace/bin/ghc-stage2`. My _new_ patch, attached as `8266_MachO_same_as_ELF.patch`, is just there to solve the latter issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 21:19:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 21:19:17 -0000 Subject: [GHC] #8366: haskeline Posix backend needs #include on Solaris In-Reply-To: <049.e865036198c31803d8a20d77075b82a9@haskell.org> References: <049.e865036198c31803d8a20d77075b82a9@haskell.org> Message-ID: <064.7057f4c4bee6413aea605637d52d6ea5@haskell.org> #8366: haskeline Posix backend needs #include on Solaris -------------------------------------+------------------------------------- Reporter: oddsignals | Owner: thoughtpolice Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: libraries | Version: 7.7 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: #8361 #8670 Blocking: | -------------------------------------+------------------------------------- Changes (by hvr): * related: 8361 => #8361 #8670 Comment: Replying to [comment:8 judahj]: > {{{ > if os(solaris) { > cpp-options: -DUSE_TERMIOS_H > } > }}} > Do you know why that's not working? Do we need to change that condition, or fix Cabal to detect Solaris correctly? see also #8670 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 21:20:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 21:20:13 -0000 Subject: [GHC] #8670: GHC fails to build on Solaris 11 In-Reply-To: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> References: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> Message-ID: <061.83ddd0b85186ff3d832d0dbb4da87d00@haskell.org> #8670: GHC fails to build on Solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Keywords: Cabal Resolution: | Architecture: x86 Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by kgardas): Yes, that's the only show-stopper now, since two other needed patches are already merged into GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 22:06:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 22:06:22 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.9f38bb0deef8b08f0c15151daca7b3d7@haskell.org> #8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by stigge): Turned out that the issue is not necessarily related to cross compiling. With: autoreconf -fi ; perl boot ; ./configure --target=x86_64-linux-gnu --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-ld=/usr/bin/ld --with-gcc=/usr/bin/gcc --with-nm=/usr/bin/nm --enable-unregisterised ; make clean ; make I get the same error. build.mk: SRC_HC_OPTS = -H64m -O0 GhcStage1HcOpts = -O GhcStage2HcOpts = -O0 GhcLibHcOpts = -O SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO INTEGER_LIBRARY = integer-simple DYNAMIC_BY_DEFAULT = NO DYNAMIC_GHC_PROGRAMS = NO GhcWithNativeCodeGen = NO GhcUnregisterised = YES -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 14 22:07:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Jan 2014 22:07:35 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.ae1b6f11f2004fc8250f18126c91f953@haskell.org> #8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+----------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by stigge): i.e. related to --enable-unregisterised. Without this option, the problem disappears. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 00:53:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 00:53:53 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.4b4fcff8ae8aabed34add7986f57c884@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): Ah! I did not notice 8266_MachO_same_as_ELF.patch. I applied it as well as Cabal's patch and started building GHC head again. It take a long time. Please wait. If Cabal's patch should not be applied, please interupt me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 03:42:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 03:42:47 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.925216274d146310de5f8a63a4b6c820@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): I should be clear: GHC generates specialized code and a rule to apply it, but the rule does not fire. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 03:52:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 03:52:56 -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.c2f6139e96a8c0e31924781c4a34f276@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): is there some way we could do a hack to do split DLLs and allow cycles? (would probably mean some sort of indirect jump penalty in one direction of the cycle). One extreme would be to use some sort of graph clustering software tool like METIS http://glaros.dtc.umn.edu/gkhome/metis/metis/overview do .hi files have enough information to sort out the directed graph of imports exports? I'd be happy to help do some graph clustering experimentation on the object files (that piece isn't windows specific, so i could hack it out on my current machine) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 03:54:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 03:54:50 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.f445f6deb1d7e8bdfaabaec00df4ef1e@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): OK. I verified that if two patches are applied, "cabal install" works as expected. That is, @rpath is properly used. One patch is not good enough. @darchon sorry for wasting your time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 04:06:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 04:06:28 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.1dd169a2915c9d1263b8c9b8c6b52f94@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by carter): Whats the current status? do I or someone else with a mac need to run a benchmark of ghc head built with clang vs ghc head built with gcc? Mind you, i only have a 2 core machine, so idk if thats enough to exercise the issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 04:09:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 04:09:44 -0000 Subject: [GHC] #7428: GHC compile times are seriously non-linear in program size In-Reply-To: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> References: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> Message-ID: <060.7fe7419e8f445f196d898a9771b79d5a@haskell.org> #7428: GHC compile times are seriously non-linear in program size ---------------------------------------+---------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by carter): I just tested this issue with a copy of HEAD I built today, ghc -O2 still blows up on the cleaned up file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 08:35:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 08:35:33 -0000 Subject: [GHC] #8671: Rebindable syntax creates bogus warning Message-ID: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> #8671: Rebindable syntax creates bogus warning -------------------------+------------------------------------------------- Reporter: | Owner: thomaseding | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Windows Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- {{{ {-# LANGUAGE RebindableSyntax #-} import Data.Void import Prelude ((.), ($), Int, id, Num(..)) (>>) :: (b -> c) -> (a -> b) -> (a -> c) (>>) = (.) return :: Void -> Void return = absurd run :: a -> (a -> b) -> b run x f = f x result :: Int result = run 8 $ do \n -> n * n id (+ 7) (* 2) }}} Compile with -Wall issues incorrect warnings. In fact the suggested fixes cause compile errors if implemented. {{{ Test.hs:22:5: Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- \ n -> (*) n n", or by using the flag -fno-warn-unused-do-bind Test.hs:23:5: Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- id", or by using the flag -fno-warn-unused-do-bind Test.hs:24:5: Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- (( \ x_ -> (+) x_ 7))", or by using the flag -fno-warn-unused-do-bind }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 09:12:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 09:12:36 -0000 Subject: [GHC] #8671: Rebindable syntax creates bogus warning In-Reply-To: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> References: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> Message-ID: <065.538bfd6db52aa63a1abb245c464291bf@haskell.org> #8671: Rebindable syntax creates bogus warning -------------------------------------------------+------------------------- Reporter: thomaseding | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Interesting. I suppose your implicit proposal is that we should suppress the do-notation-related warnings if `-XRebindableSyntax` is in force? I'd be ok with that, and it'd be easy to do. Other opinions? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 15:10:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 15:10:10 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.05904104f0dc3c139f2f1336327bf90c@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------ Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Ok, next try. This time I modified only `exprOkForSpeculation`: When checking an application, it will see if the function has a strictness signature with the `Converges` flag, and if all arguments are `exprOkForSpeculation` (they might be unlifted, hence speculation would also evaluate them), the whole expression is ok for speculation. The results are overwhelming....ly minuscule: Allocations change exactly as before: {{{ fluid -45.0% -0.1% 0.00 0.00 +0.0% -------------------------------------------------------------------------------- Min -49.5% -0.1% -15.4% -15.4% -5.7% Max -41.3% +0.0% +97.9% +97.9% +0.0% Geometric Mean -47.4% -0.0% +13.5% +13.6% -0.2% }}} (Ignore code size, one working copy had ticky-ticky enabled. Runtime number unusable, machine was not unloaded.) I looked at fluid, and it is actually quite nice what happens here: There are thunks calling `read_n_val`, which has a definition of `(.., ..)`. CPR turns that in to `(# .., .. #)`. So currently, we are allocating a thunk for the worker of `read_n_val` (which did not cancel with anything). When called, this thunk will allocate a `(..,..)` box, which later is taken apart by yet another two thunks, representing `fst ..` resp. `snd ..`. After using the `Converges` flag, we immediately call `$wread_n_val`, which returns quickly after allocating two thunks. We thereby save the allocation of `(..,..)` and the thunks for `fst ..` and `snd ..`. What is interesting is that this change did not happen in CorePrep, but already in Float Out, directly after the demand analyser. The function calling `exprOkForSpeculation` is `lvlCase`. I also measured the *static* effect of this change. When compiling GHC, the libraries and nofib, * master did 205788 calls to `exprOkForSpeculation` from `lvlCase`. Of these 7169 (3.48%) returned true, while * my branch did 206234 calls to exprOkForSpeculation` from `lvlCase`, of these 7245 (3.51%) returned true. I doubt that measuring the dynamic effect will give any more insight than what we already gain, namely: Using `Converges` in `exprOkForSpeculation` is a good idea that does not cost much in terms of implementation and does not cause programs to go bad. When it kicks in, it does nice things, but in practice the turnout is negligibly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 16:41:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 16:41:14 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.2f1300897c4b54df62c77020e48e24e1@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by thoughtpolice): I investigated Mavericks and talked with Simon about this. 10.9 is problematic. It still emits indirect jumps via a call through `%rdi` when using `__thread`, so it can't perform a simple direct load/store to a 'fast' location. You can also use `pthread_{get,set}specific`, but these are indirect dynamic calls too (and probably performs even worse.) Furthermore I can't find the source code for `pthread_getspecific` & co, so it's impossible to check if my 10.8 fix still works OK. We decided to: * Make the runtime use `__thread` on OS X for now. This cleans up the code, and in the future could be optimized by the compiler/runtime handling of TLS variables in future versions. * Document the fact OS X will suffer a performance regression with the `-threaded` garbage collector. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 21:28:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 21:28:59 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.0b694720cc7b024c1da2042a0ffd6990@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by yoeight): That did help a lot, thanks ! So, I (think) have implemented `IrredPred`. I have also fixed `DsMeta.lhs`, deleted `classP`, `equalP` and added `equalityT` Sadly,?I have a failing test `testsuite/tests/perf/compiler/T4801.hs` and I don't know how to work this out Patches can be found [https://gist.github.com/YoEight/8370987 here] Regards, Yorick -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 22:09:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 22:09:25 -0000 Subject: [GHC] #8646: Distinguish between update frames in rts/Printer.c In-Reply-To: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> References: <047.c9bbc1530fe3e38d4ff2f0e42439d2ac@haskell.org> Message-ID: <062.f3acacc11a4df9999e13ddfdf3771786@haskell.org> #8646: Distinguish between update frames in rts/Printer.c -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged in [d1712dbd2b4c5d23a60d8a369e17045a397bf4f5/ghc]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 22:18:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 22:18:48 -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.4ffe0a60d9b640d256e9ab0d4613850f@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): alternatively, if the free version of visual studio, visual studio express, http://www.visualstudio.com/en-us/products/visual-studio-express- vs.aspx comes with the Visual Studio linker, doesn't that have some support for dealing with cyclic deps in linking? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 22:43:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 22:43:46 -0000 Subject: [GHC] #8671: Rebindable syntax creates bogus warning In-Reply-To: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> References: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> Message-ID: <065.7f885bd06c9ba4b88e7e147ea50b90c3@haskell.org> #8671: Rebindable syntax creates bogus warning -------------------------------------------------+------------------------- Reporter: thomaseding | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by thomaseding): I'd be fine with simply having the warning suppressed in that case. Though I could see the warning be useful for rebound do-notation where it makes sense (e.g. monads that have restrictions on their kinds http://blog .omega-prime.co.uk/?p=127). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 15 23:06:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Jan 2014 23:06:49 -0000 Subject: [GHC] #8671: Rebindable syntax creates bogus warning In-Reply-To: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> References: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> Message-ID: <065.936b28453f8c39326e399d772af5afb1@haskell.org> #8671: Rebindable syntax creates bogus warning -------------------------------------------------+------------------------- Reporter: thomaseding | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by thomaseding): Just some initial thoughts that may or may not be useful -- concerning conditionally suppressing the warning based on what the syntax is rebound to... ---- Consider {{{ blah = do x -- suppose that GHC issues the warning for this (whether the warning is correct or not) y }}} Translates to {{{ blah = x >> y }}} Before issuing the warning, consider translating the code to {{{ blah = x >>= (\_ -> y) }}} If this compiles, then issue the warning. Otherwise do not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 09:24:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 09:24:10 -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.4c5ac5dc7f20c2687f914e5a5843ef0e@haskell.org> #8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"61395b59191284a2cc249e614bbba993c16ef8c5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="61395b59191284a2cc249e614bbba993c16ef8c5" type-rep is only broken when debugging is on in which case it is a wontfix (see #8569) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 09:24:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 09:24:35 -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.cf288cf153cb00ef79c932150826ea3b@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: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => wontfix Comment: Guess I did not update the ticket after later discussions. I believe that this is currently a wontfix: * The demand analyser is quite untyped, so in the example in comment:3, where the two branches of a case happen to have quite different types (one being a product, and one not) can only be handled on a best effort basis. Therefore, the code needs to cope with situations where a product demand does not have the right number of components for the constructor at hand. That is also the reason why `lubStr (SCall _) (SProd _)` should not panic. * The `Note [Don't optimise UProd(Used) to Used]` continues to be relevant: We differentiate these semantically equivalent terms to get some insight about how a product is being used. I believe the test suite is now set up to reflect this, i.e. type-rep will expectedly fail when GHC is compiled with `-DDEBUG` *and* the way is an optimizing way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 11:11:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 11:11:41 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.4a3d29b120a597d9f2c41ed01d7a63e7@haskell.org> #8657: -fregs-graph still has a limit on spill slots ---------------------------------------+----------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7679 ---------------------------------------+----------------------------------- Comment (by Simon Marlow ): In [changeset:"f0a7261a39bd1a8c5217fecba56c593c353f198c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f0a7261a39bd1a8c5217fecba56c593c353f198c" Disable -fregs-graph (#7679, #8657) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 11:11:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 11:11:42 -0000 Subject: [GHC] #7679: Regression in -fregs-graph performance In-Reply-To: <047.9e26897513125de7441d596a4b30ee54@haskell.org> References: <047.9e26897513125de7441d596a4b30ee54@haskell.org> Message-ID: <062.048ef259f2152376f5f238d29aebd2a0@haskell.org> #7679: Regression in -fregs-graph performance --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7192, | #8657 --------------------------------------------+------------------------------ Comment (by Simon Marlow ): In [changeset:"f0a7261a39bd1a8c5217fecba56c593c353f198c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f0a7261a39bd1a8c5217fecba56c593c353f198c" Disable -fregs-graph (#7679, #8657) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 12:41:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 12:41:43 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.815d4eebd2ce9f2e340b87f66ba440c0@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by simonpj): Where are `runRand` and `liftRand` defined? Hoogle can't find either. Google finds package `MonadRandom` on hackage, [http://hackage.haskell.org/package/MonadRandom-0.1.3/docs/Control-Monad- Random.html here], but I can't see `liftRand`. Would it be possible to rejig the example so that it doesn't use this extra package? Makes it much easier to reproduce. You don't, presumably, actually need random numbers to demonstrate the bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 15:29:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 15:29:28 -0000 Subject: [GHC] #7619: Make worker-wrapper unbox data families In-Reply-To: <043.9a9cbf73fd9ff41b12f7d52a16c9328d@haskell.org> References: <043.9a9cbf73fd9ff41b12f7d52a16c9328d@haskell.org> Message-ID: <058.8cb68af50217d3c1cc5fc018bf806af8@haskell.org> #7619: Make worker-wrapper unbox data families -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: type family Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: simonpj => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 15:32:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 15:32:13 -0000 Subject: [GHC] #6070: Fun with the demand analyser In-Reply-To: <046.c6530061559c47a83051d5bf2c366594@haskell.org> References: <046.c6530061559c47a83051d5bf2c366594@haskell.org> Message-ID: <061.11fcf8747a6d6b865363972f6c67360f@haskell.org> #6070: Fun with the demand analyser -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by simonpj: Old description: > Max writes: I've been trying to speed up the supercompiler, and in the > process > I've noticed some infelicities in the demand analyser that might be > worth looking at. > > == Infelicity 1: analysis does not take into account extra unboxing done > by the CPR transformation == > An example is: > {{{ > e :: (Int, Int) -> Int -> (Int, Int) > e x y = x `seq` if y > 10 > then x > else e x (y + 1) > }}} > Because x is seqed, the occurrence in the "then" branch gets the CPR > property so e has the CPR property overall. However, the overall > demand on x is S(AA), i.e. the demand analyser believes the x box is > used -- if the box were unused it would get the demand U(LL). So the > overall demand type is S(AA)U(L)m, and the worker looks like: > {{{ > Rec { > CPR2.$we [Occ=LoopBreaker] > :: (GHC.Types.Int, GHC.Types.Int) > -> GHC.Prim.Int# -> (# GHC.Types.Int, GHC.Types.Int #) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=DmdType S(AA)L, > Unf=OtherCon []] > CPR2.$we = > \ (w_srv :: (GHC.Types.Int, GHC.Types.Int)) > (ww_srt :: GHC.Prim.Int#) -> > case GHC.Prim.># ww_srt 10 of _ { > GHC.Types.False -> > case GHC.Prim.+# ww_srt 1 of sat_ssS { __DEFAULT -> > CPR2.$we w_srv sat_ssS > }; > GHC.Types.True -> > case w_srv of _ { (ww2_srA, ww3_srB) -> (# ww2_srA, ww3_srB #) } > } > end Rec } > }}} > But if we demand-analysed $we then GHC would say that it had the > demand type U(LL)L and unbox the pair argument! It seems silly that > the demand analyser outputs code that can be improved further by just > running demand analysis again. > > Somewhere where this really bit me in practice is in: > {{{ > d :: M.Map Int Int -> (Int, Int) > d m = M.foldrWithKey' (\k v (a, b) -> if k + v > 2 then (a, b) else > (b, a)) (0, 1) m > }}} > Which generates this inner loop: > {{{ > Rec { > CPR2.$wgo2 [Occ=LoopBreaker] > :: (GHC.Types.Int, GHC.Types.Int) > -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int > -> (# GHC.Types.Int, GHC.Types.Int #) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=DmdType S(AA)S, > Unf=OtherCon []] > CPR2.$wgo2 = > \ (w_srS :: (GHC.Types.Int, GHC.Types.Int)) > (w1_srQ :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) -> > case w1_srQ of _ { > Data.Map.Base.Tip -> > case w_srS of _ { (ww1_srW, ww2_srX) -> (# ww1_srW, ww2_srX #) }; > Data.Map.Base.Bin rb_st1 kx_ss3 x_ssa l_ssk r_ss6 -> > case kx_ss3 of _ { GHC.Types.I# x1_ssd -> > case CPR2.$wgo2 w_srS r_ss6 of _ { (# ww1_ssi, ww2_ssh #) -> > case x_ssa of _ { GHC.Types.I# y_sse -> > case GHC.Prim.+# x1_ssd y_sse of sat_st0 { __DEFAULT -> > case GHC.Prim.># sat_st0 2 of _ { > GHC.Types.False -> > let { > sat_ssZ :: (GHC.Types.Int, GHC.Types.Int) > [LclId] > sat_ssZ = (ww2_ssh, ww1_ssi) } in > CPR2.$wgo2 sat_ssZ l_ssk; > GHC.Types.True -> > let { > sat_st6 :: (GHC.Types.Int, GHC.Types.Int) > [LclId] > sat_st6 = (ww1_ssi, ww2_ssh) } in > CPR2.$wgo2 sat_st6 l_ssk > } > } > } > } > } > } > end Rec } > }}} > We can save a number of allocations proportional to the size of the > Map if the demand analyser didn't have this problem. > > I hacked up the analyser to "fix" this by changing the lines at line > 473 onward to read: > {{{ > if isTopLevel top_lvl > then fn_ty -- Don't record top level things > else case dmd of > Box (Eval (Poly Abs)) | DmdType _ _ res <- fn_ty, > returnsCPR res -> addVarDmd fn_ty var (Eval (Poly lazyDmd)) > _ > -> addVarDmd fn_ty var dmd > }}} > So if we demand a CPRish variable (such as bound by a case scrutinee > or a U(LL)-demanded lambda-binder) in the evalDmd then I throw away > the Box part of the evalDmd on the basis that after CPRing we won't > demand the box at all. > > I doubt this hack is the right solution (and I haven't tried it to see > how it affects the libraries) but perhaps it gives you some ideas. > > == Infelicity 2: a case where demand summarisation hurts us == > > I found practical examples where summarising the demand transfomer of > a function as a single strictness signature hurt us. The examples were > code like: > {{{ > h :: (Int, Int) -> Int -> (Int, Int) > h x y = if y > 10 > then x > else h (case h x 0 of (y1, y2) -> (y2, y1)) (y + 1) > }}} > If, at the innermost use of h, we re-analyse h in the demand > C(C(U(LL))) rather than just unleashing the vanilla DmdSig computed > from the demand C(C(S)) then we can unbox the pair argument. Currently > GHC just gives h the DmdType SU(L) which doesn't eliminate the > allocation of the pair at all. > > This situation occurs in practice with code like: > {{{ > c :: M.Map Int Int -> (Int, Int) > c m = M.foldrWithKey (\k v (a, b) -> if k + v > 2 then (a, b) else (b, > a)) (0, 1) m > }}} > The difference from my earlier example d is that I'm using the version > of `foldrWithKey` that doesn't call `seq`. Current GHC generates this > inner loop: > {{{ > Rec { > CPR2.c_go2 [Occ=LoopBreaker] > :: (GHC.Types.Int, GHC.Types.Int) > -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int > -> (GHC.Types.Int, GHC.Types.Int) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=DmdType U(L*)S, > Unf=OtherCon []] > CPR2.c_go2 = > \ (z_spW :: (GHC.Types.Int, GHC.Types.Int)) > (ds_spU :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) -> > case ds_spU of _ { > Data.Map.Base.Tip -> z_spW; > Data.Map.Base.Bin rb_sqq kx_sq2 x_sq9 l_sqj r_sq5 -> > case kx_sq2 of _ { GHC.Types.I# x1_sqc -> > case CPR2.c_go2 z_spW r_sq5 of wild2_sqk { (a_sqh, b_sqg) -> > case x_sq9 of _ { GHC.Types.I# y_sqd -> > case GHC.Prim.+# x1_sqc y_sqd of sat_sqp { __DEFAULT -> > case GHC.Prim.># sat_sqp 2 of _ { > GHC.Types.False -> > let { > sat_sqo :: (GHC.Types.Int, GHC.Types.Int) > [LclId] > sat_sqo = (b_sqg, a_sqh) } in > CPR2.c_go2 sat_sqo l_sqj; > GHC.Types.True -> CPR2.c_go2 wild2_sqk l_sqj > } > } > } > } > } > } > end Rec } > }}} > I implemented this but the overhead of reanalysing a function at each > occurrence site is prohibitive (with my changes paraffins took 2.5s to > compile instead of 0.3s). It does fix the problem though. > > A scheme like in "stricterness more relevant" but with let-binding > that is polymorphic in the use-site demand might be able to detect the > extra strictness here. I think Stefan Holdermanns has a paper > describing such a system. But this is anyway much harder to fix than > my first infelicity. New description: Max writes: I've been trying to speed up the supercompiler, and in the process I've noticed some infelicities in the demand analyser that might be worth looking at. One is #5949. The other is: == Infelicity 2: a case where demand summarisation hurts us == I found practical examples where summarising the demand transfomer of a function as a single strictness signature hurt us. The examples were code like: {{{ h :: (Int, Int) -> Int -> (Int, Int) h x y = if y > 10 then x else h (case h x 0 of (y1, y2) -> (y2, y1)) (y + 1) }}} If, at the innermost use of h, we re-analyse h in the demand C(C(U(LL))) rather than just unleashing the vanilla DmdSig computed from the demand C(C(S)) then we can unbox the pair argument. Currently GHC just gives h the DmdType SU(L) which doesn't eliminate the allocation of the pair at all. This situation occurs in practice with code like: {{{ c :: M.Map Int Int -> (Int, Int) c m = M.foldrWithKey (\k v (a, b) -> if k + v > 2 then (a, b) else (b, a)) (0, 1) m }}} The difference from my earlier example d is that I'm using the version of `foldrWithKey` that doesn't call `seq`. Current GHC generates this inner loop: {{{ Rec { CPR2.c_go2 [Occ=LoopBreaker] :: (GHC.Types.Int, GHC.Types.Int) -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int -> (GHC.Types.Int, GHC.Types.Int) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType U(L*)S, Unf=OtherCon []] CPR2.c_go2 = \ (z_spW :: (GHC.Types.Int, GHC.Types.Int)) (ds_spU :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) -> case ds_spU of _ { Data.Map.Base.Tip -> z_spW; Data.Map.Base.Bin rb_sqq kx_sq2 x_sq9 l_sqj r_sq5 -> case kx_sq2 of _ { GHC.Types.I# x1_sqc -> case CPR2.c_go2 z_spW r_sq5 of wild2_sqk { (a_sqh, b_sqg) -> case x_sq9 of _ { GHC.Types.I# y_sqd -> case GHC.Prim.+# x1_sqc y_sqd of sat_sqp { __DEFAULT -> case GHC.Prim.># sat_sqp 2 of _ { GHC.Types.False -> let { sat_sqo :: (GHC.Types.Int, GHC.Types.Int) [LclId] sat_sqo = (b_sqg, a_sqh) } in CPR2.c_go2 sat_sqo l_sqj; GHC.Types.True -> CPR2.c_go2 wild2_sqk l_sqj } } } } } } end Rec } }}} I implemented this but the overhead of reanalysing a function at each occurrence site is prohibitive (with my changes paraffins took 2.5s to compile instead of 0.3s). It does fix the problem though. A scheme like in "stricterness more relevant" but with let-binding that is polymorphic in the use-site demand might be able to detect the extra strictness here. I think Stefan Holdermanns has a paper describing such a system. But this is anyway much harder to fix than my first infelicity. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 15:32:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 15:32:42 -0000 Subject: [GHC] #5949: Demand analysis attributes manifestly wrong demand type In-Reply-To: <053.1474bb3b64c7d2e5ae4b0124510e17fc@haskell.org> References: <053.1474bb3b64c7d2e5ae4b0124510e17fc@haskell.org> Message-ID: <068.ab65a72e36e2a9592ad628a023531f56@haskell.org> #5949: Demand analysis attributes manifestly wrong demand type --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.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: --------------------------------------------+------------------------------ Description changed by simonpj: Old description: > (Further to my email to Simon, adding to bug tracker so it doesn't get > lost) > > Consider: > > {{{ > e :: (Int, Int) -> Int -> (Int, Int) > e x y = x `seq` if y > 10 > then x > else e x (y + 1) > }}} > > After worker/wrapper we get: > > {{{ > Rec { > CPR2.$we [Occ=LoopBreaker] > :: (GHC.Types.Int, GHC.Types.Int) > -> GHC.Prim.Int# -> (# GHC.Types.Int, GHC.Types.Int #) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=DmdType S(AA)L, > Unf=OtherCon []] > CPR2.$we = > \ (w_srv :: (GHC.Types.Int, GHC.Types.Int)) > (ww_srt :: GHC.Prim.Int#) -> > case GHC.Prim.># ww_srt 10 of _ { > GHC.Types.False -> > case GHC.Prim.+# ww_srt 1 of sat_ssS { __DEFAULT -> > CPR2.$we w_srv sat_ssS > }; > GHC.Types.True -> > case w_srv of _ { (ww2_srA, ww3_srB) -> (# ww2_srA, ww3_srB #) } > } > end Rec } > }}} > > The demand type S(AA) is entirely wrong because the box is unused (so it > should be U(AA)) and because the two components are not absent -- they > are used. > > This leads to the worker/wrapper transformation being insufficiently > agressive. This bites in practice with examples like: > > {{{ > d :: M.Map Int Int -> (Int, Int) > d m = M.foldrWithKey' (\k v (a, b) -> if k + v > 2 then (a, b) else > (b, a)) (0, 1) m > }}} > > Which generates this inner loop: > > {{{ > Rec { > CPR2.$wgo2 [Occ=LoopBreaker] > :: (GHC.Types.Int, GHC.Types.Int) > -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int > -> (# GHC.Types.Int, GHC.Types.Int #) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=DmdType S(AA)S, > Unf=OtherCon []] > CPR2.$wgo2 = > \ (w_srS :: (GHC.Types.Int, GHC.Types.Int)) > (w1_srQ :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) -> > case w1_srQ of _ { > Data.Map.Base.Tip -> > case w_srS of _ { (ww1_srW, ww2_srX) -> (# ww1_srW, ww2_srX #) }; > Data.Map.Base.Bin rb_st1 kx_ss3 x_ssa l_ssk r_ss6 -> > case kx_ss3 of _ { GHC.Types.I# x1_ssd -> > case CPR2.$wgo2 w_srS r_ss6 of _ { (# ww1_ssi, ww2_ssh #) -> > case x_ssa of _ { GHC.Types.I# y_sse -> > case GHC.Prim.+# x1_ssd y_sse of sat_st0 { __DEFAULT -> > case GHC.Prim.># sat_st0 2 of _ { > GHC.Types.False -> > let { > sat_ssZ :: (GHC.Types.Int, GHC.Types.Int) > [LclId] > sat_ssZ = (ww2_ssh, ww1_ssi) } in > CPR2.$wgo2 sat_ssZ l_ssk; > GHC.Types.True -> > let { > sat_st6 :: (GHC.Types.Int, GHC.Types.Int) > [LclId] > sat_st6 = (ww1_ssi, ww2_ssh) } in > CPR2.$wgo2 sat_st6 l_ssk > } > } > } > } > } > } > end Rec } > }}} > > Note that it allocates a pair every go around the loop. If we just ran > the demand analyser on this code again we could eliminate this > allocation, but the demand analyser shouldn't be generating code which > has these manifest problems. > > One way to fix this is to change the ending of dmdTransform to read: > > {{{ > if isTopLevel top_lvl > then fn_ty -- Don't record top level things > else case dmd of > Box (Eval (Poly Abs)) | DmdType _ _ res <- fn_ty, > returnsCPR res -> addVarDmd fn_ty var (Eval (Poly lazyDmd)) > _ > -> addVarDmd fn_ty var dmd > }}} > > But this is a hack. Better suggestions welcome. New description: Consider: {{{ e :: (Int, Int) -> Int -> (Int, Int) e x y = x `seq` if y > 10 then x else e x (y + 1) }}} After worker/wrapper we get: {{{ Rec { CPR2.$we [Occ=LoopBreaker] :: (GHC.Types.Int, GHC.Types.Int) -> GHC.Prim.Int# -> (# GHC.Types.Int, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType S(AA)L, Unf=OtherCon []] CPR2.$we = \ (w_srv :: (GHC.Types.Int, GHC.Types.Int)) (ww_srt :: GHC.Prim.Int#) -> case GHC.Prim.># ww_srt 10 of _ { GHC.Types.False -> case GHC.Prim.+# ww_srt 1 of sat_ssS { __DEFAULT -> CPR2.$we w_srv sat_ssS }; GHC.Types.True -> case w_srv of _ { (ww2_srA, ww3_srB) -> (# ww2_srA, ww3_srB #) } } end Rec } }}} The demand type S(AA) is entirely wrong because the box is unused (so it should be U(AA)) and because the two components are not absent -- they are used. This leads to the worker/wrapper transformation being insufficiently agressive. This bites in practice with examples like: {{{ d :: M.Map Int Int -> (Int, Int) d m = M.foldrWithKey' (\k v (a, b) -> if k + v > 2 then (a, b) else (b, a)) (0, 1) m }}} Which generates this inner loop: {{{ Rec { CPR2.$wgo2 [Occ=LoopBreaker] :: (GHC.Types.Int, GHC.Types.Int) -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int -> (# GHC.Types.Int, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType S(AA)S, Unf=OtherCon []] CPR2.$wgo2 = \ (w_srS :: (GHC.Types.Int, GHC.Types.Int)) (w1_srQ :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) -> case w1_srQ of _ { Data.Map.Base.Tip -> case w_srS of _ { (ww1_srW, ww2_srX) -> (# ww1_srW, ww2_srX #) }; Data.Map.Base.Bin rb_st1 kx_ss3 x_ssa l_ssk r_ss6 -> case kx_ss3 of _ { GHC.Types.I# x1_ssd -> case CPR2.$wgo2 w_srS r_ss6 of _ { (# ww1_ssi, ww2_ssh #) -> case x_ssa of _ { GHC.Types.I# y_sse -> case GHC.Prim.+# x1_ssd y_sse of sat_st0 { __DEFAULT -> case GHC.Prim.># sat_st0 2 of _ { GHC.Types.False -> let { sat_ssZ :: (GHC.Types.Int, GHC.Types.Int) [LclId] sat_ssZ = (ww2_ssh, ww1_ssi) } in CPR2.$wgo2 sat_ssZ l_ssk; GHC.Types.True -> let { sat_st6 :: (GHC.Types.Int, GHC.Types.Int) [LclId] sat_st6 = (ww1_ssi, ww2_ssh) } in CPR2.$wgo2 sat_st6 l_ssk } } } } } } end Rec } }}} Note that it allocates a pair every go around the loop. If we just ran the demand analyser on this code again we could eliminate this allocation, but the demand analyser shouldn't be generating code which has these manifest problems. One way to fix this is to change the ending of dmdTransform to read: {{{ if isTopLevel top_lvl then fn_ty -- Don't record top level things else case dmd of Box (Eval (Poly Abs)) | DmdType _ _ res <- fn_ty, returnsCPR res -> addVarDmd fn_ty var (Eval (Poly lazyDmd)) _ -> addVarDmd fn_ty var dmd }}} But this is a hack. Better suggestions welcome. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 15:41:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 15:41:45 -0000 Subject: [GHC] #5949: Demand analysis attributes manifestly wrong demand type In-Reply-To: <053.1474bb3b64c7d2e5ae4b0124510e17fc@haskell.org> References: <053.1474bb3b64c7d2e5ae4b0124510e17fc@haskell.org> Message-ID: <068.92db365c7ae497446445223ede705718@haskell.org> #5949: Demand analysis attributes manifestly wrong demand type --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: 7.8.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: --------------------------------------------+------------------------------ Changes (by simonpj): * owner: => nomeata Comment: Seems fixed; Joachim will add a perf test to make sure it stays fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 16:00:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 16:00:41 -0000 Subject: [GHC] #4267: Strictness analyser is to conservative about passing a boxed parameter In-Reply-To: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> References: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> Message-ID: <059.a5b4ecacb5f54d42ffd3105a3b5b7df7@haskell.org> #4267: Strictness analyser is to conservative about passing a boxed parameter -------------------------------------+------------------------------------ Reporter: tibbe | Owner: nomeata Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => nomeata * difficulty: => Unknown Comment: All versions give good code now, happily! Worth adding a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 16:04:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 16:04:28 -0000 Subject: [GHC] #8670: GHC fails to build on Solaris 11 In-Reply-To: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> References: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> Message-ID: <061.fe5c4efda3d0219ad8eb264e3226af3a@haskell.org> #8670: GHC fails to build on Solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Keywords: Cabal Resolution: | Architecture: x86 Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"b41821b43925db46c968f1244712c78877204a9b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b41821b43925db46c968f1244712c78877204a9b" Update to current Cabal 1.18 branch tip This should contain a fix that addresses the Solaris build breakage (see #8670) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 16:05:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 16:05:47 -0000 Subject: [GHC] #8670: GHC fails to build on Solaris 11 In-Reply-To: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> References: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> Message-ID: <061.f5fee16ce2932754892f6b59bbfb2791@haskell.org> #8670: GHC fails to build on Solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Keywords: Cabal Resolution: | Architecture: x86 Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:2 kgardas]: > Yes, that's the only show-stopper now, since two other needed patches are already merged into GHC HEAD. ...now that I've updated `libraries/Cabal`, can you verify it works for you now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 16:55:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 16:55:22 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.d5da18c52cabda36a45008661a9e42a2@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): Right you are. The links are fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 18:01:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 18:01:41 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.12666b5b7fd8f4ff2eb732870520703d@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): This patch makes static built win64 GHC 7.6.3 work. I think this patch will apply cleanly to HEAD too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 18:03:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 18:03:11 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.ddea12c845002ebb2ebccd95b81ffdf5@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by awson): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 18:04:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 18:04:56 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.aa137606cc9103e4212a442afac2eae5@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by simonpj): Thanks that's helpful. I can now at least compile it. One complicating factor is that you have a `Num` instance for `FastCyc`. You could simplify the setup by calling `plusFastCyc` in `cyclotomicTimeTest`, and defining {{{ plusFastCyc :: Num (t r) => FastCyc t r -> FastCyc t r -> FastCyc t r plusFastCyc (PowBasis v1) (PowBasis v2) = PowBasis $ v1 + v2 plusFastCyc p1@(DecBasis _) p2@(PowBasis _) = (g p1) + p2 plusFastCyc p1@(PowBasis _) p2@(DecBasis _) = p1 + (g p2) plusFastCyc p1 p2 = (g p1) + (g p2) }}} Now you can write your specilise pragmas (or not) for that. Do you get the same behaviour? That would elminate one source of complexity. Can you say in more detail what you ''expect'' to happen? The slow version (could we call it `slow` rather than `cyclotomicTimeTest`?) iterates `plusFastCyc` which necessariliy does a lot more work unpacking and packing those `PowBasis` constructors. Are you ok with that? But you aren't ok with ''something''. In short, it's a bit complicated for me to understand the problem. Maybe you can show some `-ddump-simpl` core and say "this call here should be specialsed, why doesn't the rule fire? Incidentally, if you want GHC to auto-specialise an '''imported''' function, to types that may not even be in scope in the defining module, you should mark that function as `INLINABLE` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 18:14:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 18:14:00 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.c82462a090db764eef2690f5513fb579@haskell.org> #8566: Given kind equalities are discarded --------------------------------------------+------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: polykinds/T8566, T8566a | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * testcase: polykinds/T8566 => polykinds/T8566, T8566a Comment: OK fine. Let's do nothing. I'll add a test `polykinds/T8566a` that fails to compile because of the lack of given kind-equalities, and mark it "expect_broken". Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 18:47:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 18:47:05 -0000 Subject: [GHC] #8670: GHC fails to build on Solaris 11 In-Reply-To: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> References: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> Message-ID: <061.807acf509b47153e63bd40aa9f594030@haskell.org> #8670: GHC fails to build on Solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Keywords: Cabal Resolution: | Architecture: x86 Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by kgardas): Herbert, thanks for merging Cabal 1.18 branch. I have verified and yes, GHC HEAD builds well on my Solaris 11 using GHC 7.6.3 and other required tools. Thanks for this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 18:47:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 18:47:42 -0000 Subject: [GHC] #8670: GHC fails to build on Solaris 11 In-Reply-To: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> References: <046.f2e0377841ac947c15762be89fa9d942@haskell.org> Message-ID: <061.f4398718b2a2f8a91ab9bf22959289d4@haskell.org> #8670: GHC fails to build on Solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Keywords: Cabal Resolution: fixed | Architecture: x86 Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by kgardas): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 18:55:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 18:55:55 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.43e7ddb9ef33ef1ff4f367688388a4f4@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): Also we can now get rid of bigaddr=0 ugly hack for 7.6. HEAD does not contain it anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 19:20:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 19:20:34 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.54bec58750cefb771b57e27018666b43@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): I updated the files again per your suggestion, and get identical behavior. I expect the `vtTest` (currently fast) and `fcTest` (currently slow) to have the same runtime, e.g. < 2 seconds runtime difference. The two functions are doing the same work, but `fcTest` has one more level of indirection (one more wrapper on the type, and one more function call per addition). As far as "doing a lot of work unpacking `Pow` constructors", `plusFastCyc` is iterated 100 times, but the runtime difference is 1 minute 18 seconds. I'm willing to pay for 100 function calls, but I think we can agree that something more is going on than just unpacking constructors. I put some core snippets here [http://lpaste.net/98593] This was compiled with -O3 using the `forall`'d SPECIALIZATION. On line 10, you can see that GHC does write a specialized version of `plusFastCyc`, compared to the generic version on line 167. The rule for the specialization is on line 225. I believe this rule should fire on line 270. (`main6` calls `iterate main8 y`, so `main8` is where `plusFastCyc` should be specialized.) In regards to GHC auto-specializing: if I do not explicitly specialize `plusFastCyc` at all (but still mark it as `INLINABLE`), `fcTest` is slow. If instead I specialize `plusFastCyc` with concrete types as in the comment, `fcTest` is fast. Thus it appears GHC is *not* auto-specializing `plusFastCyc`, despite it being marked as `INLINABLE`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 20:54:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 20:54:01 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.e498e7f676c4900ffbf24849204225be@haskell.org> #8566: Given kind equalities are discarded --------------------------------------------+------------------------------ Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: polykinds/T8566, T8566a | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Closing ticket, in agreement with Simon. (Closing it as "fixed" because the original bug is indeed fixed.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 21:46:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 21:46:53 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.64bf031adafb5fc6e48c54c06ba9a26e@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by carter): Inlinable is known to prevent specialization from firing. (unless my recollection is wrong, has something to do with the order of the relevant passes in ghc afaik) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 23:07:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 23:07:08 -0000 Subject: [GHC] #8672: :browse and roles on typefamilies Message-ID: <047.79fcde45b99494808022df1c15fe6d9a@haskell.org> #8672: :browse and roles on typefamilies -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- :browse on `ghci tests/ghci.debugger/scripts/T8557.hs` outputs a weird looking line: {{{ type role Sing nominal data family Sing (a :: k) type role T8557.R:Sing[]a nominal <-- data instance Sing a = SNil }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 16 23:20:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Jan 2014 23:20:05 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.5a9466684ce4f5b5eebf804f1e0c7cc7@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"0476327376045838375fbbe4a78c02859a1913cb/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="0476327376045838375fbbe4a78c02859a1913cb" Dont use big/small-int primops on IL32P64 (i.e. Win/x86_64) for now This is due to `mpz_*()` functions having @long@ arguments which are 32bit on IL32P64, whereas `Int#` and `Word#` are 64bit wide, causing all sorts of malfunction due to truncation. This affects mostly the new big/small-int primops introduced in the course of #8647, so when `SIZEOF_W != SIZEOF_LONG` we simply fall back to using the big/big-int primops. big/small primops implemented via the low-level `mpn_*()` GMP operations are not affected, as those use `mp_limb_t` arguments. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 02:15:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 02:15:55 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.52869b3d63ff8cabaf58593c8953c40e@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): Replying to [comment:6 carter]: > Inlinable is known to prevent specialization from firing. (unless my recollection is wrong, has something to do with the order of the relevant passes in ghc afaik) I tried removing the `INLINABLE`s, but that didn't help. I was under the impression that at least for auto-specialization across modules, `INLINABLE` is ''required''. I've also tried playing around with phase control (just a little) to avoid inlining/specialization order problems, but I couldn't get that to work either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 04:27:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 04:27:58 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.44076710e76dc9ab68768b3a0f9fc36f@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by carter): If you write the SPECIALIZE pragma instance in the defining module for the operation (assuming the associated class instances specialize too, check that they can specialize mebe?), you don't need the INLINEABLE (unless you want other instances to be specialized). what happens when you go one step in the other direction and use INLINE? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 05:01:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 05:01:12 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.30ee055ac8e2aab4a6aeab42ed4c3083@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): For the small example above, GHC simply inlines everything and both main functions are equally fast. However, I tried this in my real code and the equivalent of plusFastCyc is too large for GHC to inline (even with `INLINE` pragmas), and used in too many places for that to be a good solution even if it did work. That's why I'm trying to make GHC call a specialized function instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 06:31:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 06:31:36 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.92c7da7591808315afd6d3a749cf0044@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by carter): did you try doing a specialize on (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) without the class constraint? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 08:05:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 08:05:48 -0000 Subject: [GHC] #8673: GHC could generate GADT record selectors in more cases Message-ID: <046.d1195e7d3c4ca30e9d2a1c73eb0a6ed3@haskell.org> #8673: GHC could generate GADT record selectors in more cases ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Philip Holzenspies writes (in email to ghc-users): I was playing around with GADT-records again and ran into behaviour that I'm not sure is intentional. Given this program: {{{ {-#LANGUAGE GADTs #-} data FooBar x a where Foo :: { fooBar :: a } -> FooBar Char a Bar :: { fooBar :: a } -> FooBar Bool a }}} GHC tells me this: {{{ foo.hs:3:1: Constructors Foo and Bar have a common field `fooBar', but have different result types In the data declaration for `FooBar' Failed, modules loaded: none. }}} The user guide does say (section 7.4.7): "However, for GADTs there is the following additional constraint: every constructor that has a field f must have the same result type (modulo alpha conversion)." So this behaviour is documented in the user guide. However, it seems reasonable that in the case above, where all the relevant variables are exposed in the result type of both constructors, this should be perfectly typeable. In other words, shouldn't GHC be able to derive a type that is simply: {{{ fooBar :: FooBar x a -> a }}} ? Is this something that was simply never implemented, but could be, or is this not decidable or prohibitively computationally complex? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 08:07:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 08:07:34 -0000 Subject: [GHC] #8673: GHC could generate GADT record selectors in more cases In-Reply-To: <046.d1195e7d3c4ca30e9d2a1c73eb0a6ed3@haskell.org> References: <046.d1195e7d3c4ca30e9d2a1c73eb0a6ed3@haskell.org> Message-ID: <061.284720d239fa0b34dccd184add01fb44@haskell.org> #8673: GHC could generate GADT record selectors in more cases -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Old description: > Philip Holzenspies writes (in email to ghc-users): > I was playing around with GADT-records again and ran into behaviour that > I'm not sure is intentional. Given this program: > {{{ > {-#LANGUAGE GADTs #-} > > data FooBar x a where > Foo :: { fooBar :: a } -> FooBar Char a > Bar :: { fooBar :: a } -> FooBar Bool a > }}} > GHC tells me this: > {{{ > foo.hs:3:1: > Constructors Foo and Bar have a common field `fooBar', > but have different result types > In the data declaration for `FooBar' > Failed, modules loaded: none. > }}} > > The user guide does say (section 7.4.7): "However, for GADTs there is > the following additional constraint: every constructor that has a field > f must have the same result type (modulo alpha conversion)." So this > behaviour is documented in the user guide. However, it seems reasonable > that in the case above, where all the relevant variables are exposed in > the result type of both constructors, this should be perfectly typeable. > In other words, shouldn't GHC be able to derive a type that is simply: > {{{ > fooBar :: FooBar x a -> a > }}} > ? > > Is this something that was simply never implemented, but could be, or is > this not decidable or prohibitively computationally complex? New description: Philip Holzenspies writes (in email to ghc-users): I was playing around with GADT-records again and ran into behaviour that I'm not sure is intentional. Given this program: {{{ {-#LANGUAGE GADTs #-} data FooBar x a where Foo :: { fooBar :: a } -> FooBar Char a Bar :: { fooBar :: a } -> FooBar Bool a }}} GHC tells me this: {{{ foo.hs:3:1: Constructors Foo and Bar have a common field `fooBar', but have different result types In the data declaration for `FooBar' Failed, modules loaded: none. }}} The user guide does say (section 7.4.7): "However, for GADTs there is the following additional constraint: every constructor that has a field f must have the same result type (modulo alpha conversion)." So this behaviour is documented in the user guide. However, it seems reasonable that in the case above, where all the relevant variables are exposed in the result type of both constructors, this should be perfectly typeable. In other words, shouldn't GHC be able to derive a type that is simply: {{{ fooBar :: FooBar x a -> a }}} ? Is this something that was simply never implemented, but could be, or is this not decidable or prohibitively computationally complex? -- Comment (by simonpj): Consider {{{ data Bar a where B1 :: { x :: b } -> Bar [b] B2 :: { x :: b } -> Bar [b] B3 :: Bar a }}} Now we can define a perfectly good selector {{{ x :: Bar [b] -> b x (B1 v) = v x (B2 v) = v }}} But this wouldn't work if the result types were different {{{ data BadBar a where B1 :: { x :: b } -> Bar [b] B2 :: { x :: b } -> Bar b B3 :: Bar a }}} Now it's true that in your example the field mentions only *polymorphic* components, so there is a perfectly well-defined selector with the type you give. Indeed, it could be a bit more complicated: {{{ data FooBar x a where Foo :: { fooBar :: a } -> FooBar Char [a] Bar :: { fooBar :: a } -> FooBar Bool [a] }}} Then there is a reasonable selector with type {{{ fooBar :: FooBar b [a] -> a }}} So what is the general rule? When exactly is there a well-defined selector type, and what is that type? Notice that in the type of fooBar we had to generalise over the Char/Bool difference, but maintain the [a] part. Indeed it might all be part of one type: {{{ data FooBar2 x where Foo2 :: { fooBar2 :: a } -> FooBar2 (Char, [a]) Bar2 :: { fooBar2 :: a } -> FooBar2 (Bool, [a]) }}} So now {{{ fooBar2 :: FooBar2 (x, [a]) -> a }}} where we generalise part of the type. So, on reflection, there must be a more permissive rule than the one GHC currently implements. If someone wants to figure out the general rule, express it formally, say what the user manual would say, we could discuss whether the cost benefit ratio is good enough to be worth implementing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 10:04:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 10:04:32 -0000 Subject: [GHC] #8672: :browse and roles on typefamilies In-Reply-To: <047.79fcde45b99494808022df1c15fe6d9a@haskell.org> References: <047.79fcde45b99494808022df1c15fe6d9a@haskell.org> Message-ID: <062.6735805b67075e0d33ac392b9786761e@haskell.org> #8672: :browse and roles on typefamilies -------------------------------------------------+------------------------- Reporter: monoidal | Owner: Type: bug | goldfire Priority: low | Status: new Component: Compiler (Type checker) | Milestone: Resolution: | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * owner: => goldfire Comment: The reason this is happening is because `SNil` is defined, so GHC is showing the appropriate `data instance`. Then it tries to show the roles of the data instance, and does so badly. Richard, two questions. First in this case, can't the data instance have a representational role inferred? Eg this ought to work. The definition of `g` is currently rejected. {{{ data family T a data instance T [b] = MkT b newtype Age = MkAge Int g :: T [Age] -> T [Int] g x = coerce x }}} Second question. Are role annotations allowed on data family declarations, where they could indicate which parameters are the indices: {{{ type role T representational nominal -- Only second param can be an index data family T a b data instance T a Bool = ... -- Allowed data instance T Bool b = ... -- Rejected }}} (And similarly for type families.) Similarly are role annotations allowed on data instance declarations, where they would be useful in exactly the same way that they are on data decls {{{ data family T a type role T [a] (a:nominal) data instance T [a] = MkT a }}} Here we are running out of syntax! This isn't supported now because I think all parameters are automatically nominal (see point 1 for why they shouldn't be). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 10:15:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 10:15:39 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.510e3dff0bbca1d41c5c52552ec47b6f@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by simonmar): Great work! I wonder whether it might be better to allocate a single space for the trampolines like we do for other platforms (see `ocAllocateSymbolExtras`), rather than a separate allocation for each symbol. Do these allocations ever get freed again? See `freeObjectCode`. Neither of these is a blocker, if this makes GHCi work we should just get it in and make tickets for remaining issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 10:42:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 10:42:59 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.4b0c5196a962dac6ba35b6fdd78db3dc@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): These allocations are not freed. I don't know Linker.c perfectly yet. From what I saw, I've got am impression there are some other things which are not freed and I've decided to ignore this for a while to be in time for 7.8, because it is too painful to not have working GHC for 64-bit windows (not only we have no repl, we also have no any (indirectly)TH-dependent code i.e. we have virtually nothing nontrivial at all). But thanks for references! I'll look into them and will try to make things better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 13:32:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 13:32:46 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.7ee34f32734dab582f2a8711016e4cfd@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Changes (by awson): * cc: hvr (added) Comment: This patch solves the problem. The patch is made against 7.6.3 *with* the patch https://ghc.haskell.org/trac/ghc/attachment/ticket/7134/ghc-7.6.3-w64fix.patch applied. These two also should apply to HEAD cleanly in order. This patch is *especially* important for 64-bit build because it is distributed with mingw-w64 gcc compiler, having {{{__declspec(dllimport)}}} as part of windows api specs in header files. Hence even C/C++ sources built via GHC driver refer to win32 API functions, decorated with {{{__imp_}}} prefix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 13:41:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 13:41:15 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.0ec10565e908549d6d395443a6e94fdc@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Changes (by awson): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 14:01:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 14:01:21 -0000 Subject: [GHC] #8674: User output should not show eta-contracted data instances Message-ID: <046.8254b31e4be9ab59e8bfa616f0f1f785@haskell.org> #8674: User output should not show eta-contracted data instances ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider {{{ data family Sing (a :: k) data instance Sing (a :: [k]) = SNil data instance Sing Bool = SBool }}} If you load this into ghci and say `:info Sing` you get {{{ :i Sing type role Sing nominal data family Sing (a :: k) -- Defined at T8557.hs:4:1 data instance Sing Bool -- Defined at T8557.hs:6:15 data instance Sing -- Defined at T8557.hs:5:15 }}} The `data instance` is eta-contracted (see `Note [Eta reduction for data family axioms]` in `TcInstDcls`). This is jolly confusing for our users. We should eta-expand before displaying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 14:07:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 14:07:07 -0000 Subject: [GHC] #8674: User output should not show eta-contracted data instances In-Reply-To: <046.8254b31e4be9ab59e8bfa616f0f1f785@haskell.org> References: <046.8254b31e4be9ab59e8bfa616f0f1f785@haskell.org> Message-ID: <061.3b8270707b2a4e1499ca2a312c69d073@haskell.org> #8674: User output should not show eta-contracted data instances ---------------------------------------+----------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8674 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghci/scripts/T8674 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 14:07:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 14:07:20 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.d971a8f9f81db6d4480b9defb9be9c37@haskell.org> #8566: Given kind equalities are discarded --------------------------------------------+------------------------------ Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: polykinds/T8566, T8566a | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"45d825bb8ba659696788aca712b6f5d2b15a05cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="45d825bb8ba659696788aca712b6f5d2b15a05cf" Add an expect-broken test for Trac #8566 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 14:07:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 14:07:21 -0000 Subject: [GHC] #8674: User output should not show eta-contracted data instances In-Reply-To: <046.8254b31e4be9ab59e8bfa616f0f1f785@haskell.org> References: <046.8254b31e4be9ab59e8bfa616f0f1f785@haskell.org> Message-ID: <061.4e563930168c18d1184ecf3111a90061@haskell.org> #8674: User output should not show eta-contracted data instances ---------------------------------------+----------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8674 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"44dc0aad5b14f39b2fbc618626bf2446dddcb78b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="44dc0aad5b14f39b2fbc618626bf2446dddcb78b" Eta expand data family instances before printing them Fixes Trac #8674 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 14:07:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 14:07:21 -0000 Subject: [GHC] #8672: :browse and roles on typefamilies In-Reply-To: <047.79fcde45b99494808022df1c15fe6d9a@haskell.org> References: <047.79fcde45b99494808022df1c15fe6d9a@haskell.org> Message-ID: <062.3a58d7e1e30593fa4750bc69dc217f39@haskell.org> #8672: :browse and roles on typefamilies -------------------------------------------------+------------------------- Reporter: monoidal | Owner: Type: bug | goldfire Priority: low | Status: new Component: Compiler (Type checker) | Milestone: Resolution: | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0f7381bfb382f9fd7d18ebfc1a436237e6f2e21d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0f7381bfb382f9fd7d18ebfc1a436237e6f2e21d" Don't print roles for data instances See Trac #8672 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 15:11:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 15:11:58 -0000 Subject: [GHC] #5949: Demand analysis attributes manifestly wrong demand type In-Reply-To: <053.1474bb3b64c7d2e5ae4b0124510e17fc@haskell.org> References: <053.1474bb3b64c7d2e5ae4b0124510e17fc@haskell.org> Message-ID: <068.278ebae1f8c3d15ebab7895951ac16c7@haskell.org> #5949: Demand analysis attributes manifestly wrong demand type --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: 7.8.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 Joachim Breitner ): In [changeset:"19e09df47f48707718150fb9b4b9135ec742bed2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="19e09df47f48707718150fb9b4b9135ec742bed2" Add a test case for #5949 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 15:11:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 15:11:59 -0000 Subject: [GHC] #4267: Strictness analyser is to conservative about passing a boxed parameter In-Reply-To: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> References: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> Message-ID: <059.495fc0679f88814e2a704c986b1ca56e@haskell.org> #4267: Strictness analyser is to conservative about passing a boxed parameter -------------------------------------+------------------------------------ Reporter: tibbe | Owner: nomeata Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 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 Joachim Breitner ): In [changeset:"20b1a0772a6f830cbfba016baea99628a792bb7b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="20b1a0772a6f830cbfba016baea99628a792bb7b" Add testcase for #4267 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 15:12:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 15:12:14 -0000 Subject: [GHC] #5949: Demand analysis attributes manifestly wrong demand type In-Reply-To: <053.1474bb3b64c7d2e5ae4b0124510e17fc@haskell.org> References: <053.1474bb3b64c7d2e5ae4b0124510e17fc@haskell.org> Message-ID: <068.c9fbc0c0bf2651dd8226662c4dfcb520@haskell.org> #5949: Demand analysis attributes manifestly wrong demand type --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 15:12:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 15:12:20 -0000 Subject: [GHC] #4267: Strictness analyser is to conservative about passing a boxed parameter In-Reply-To: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> References: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> Message-ID: <059.523e9cd1e09f8de35b811d76e4ecb134@haskell.org> #4267: Strictness analyser is to conservative about passing a boxed parameter -------------------------------------+------------------------------------ Reporter: tibbe | Owner: nomeata Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 15:27:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 15:27:04 -0000 Subject: [GHC] #8313: Poor performance of higher-order functions with unboxing In-Reply-To: <044.b6968c03bf741916b66e492dab74ef19@haskell.org> References: <044.b6968c03bf741916b66e492dab74ef19@haskell.org> Message-ID: <059.b12af089be778553ef2d50577be04364@haskell.org> #8313: Poor performance of higher-order functions with unboxing -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: slow unboxed Operating System: Unknown/Multiple | higher order Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: 6084 | Related Tickets: -------------------------------------+------------------------------------- Comment (by nomeata): Checking if this is really fixed, but here, `manual` is still slower than `auto`, so it does not seem to be fixed (although it might have been even slower before). Also, `manual` allocates much more ? is that the symptom of this problem, or is it something else? I had slightly change the test due to [f6e2398adb63f5c35544333268df9c8837fd2581/base] to {{{#!haskell {-# LANGUAGE BangPatterns #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE MagicHash #-} import GHC.Exts import System.Environment rel# :: Int# -> Int# -> Int# -> Int# rel# i# j# k# = (i# +# j# +# k#) ># 100000000# rel :: Int -> Int -> Int -> Bool rel (I# i#) (I# j#) (I# k#) = tagToEnum# (rel# i# j# k#) manual :: (Int# -> Int# -> Int# -> Int#) -> (Int, Int, Int) manual r# = go 0# 0# 0# where go i# j# k# | tagToEnum# (r# i# j# k#) = (I# i#, I# j#, I# k#) | otherwise = go j# k# (i# +# 1#) {-# NOINLINE manual #-} auto :: (Int -> Int -> Int -> Bool) -> (Int, Int, Int) auto r = go 0 0 0 where go !i !j !k | r i j k = (i, j, k) | otherwise = go j k (i+1) {-# NOINLINE auto #-} main = getArgs >>= \case "manual" : _ -> print $ manual rel# -- This case is significantly slower. "auto" : _ -> print $ auto rel -- Why? }}} and I get these numbers: {{{ $ ./T8313 manual +RTS -t (33333333,33333334,33333334) <> $ ./T8313 auto +RTS -t (33333333,33333334,33333334) <> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 15:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 15:45:32 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.2cf453b23f3d53220b7b8e2c84fd5c26@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Yesterday it looked as if this has magically improved, but at least with the example from the ticket, put into self-contained as follows: {{{#!haskell module Foo( foo ) where import Data.Complex import Prelude hiding (sum, foldl) foldl k z xs = foldr (\v fn z -> fn (k z v)) id xs z {-# INLINE foldl #-} sum = foldl (+) 0 {-# INLINE sum #-} foo x = sum [f n | n <- [1 .. x]] f :: Int -> Complex Double {-# NOINLINE f #-} f n = mkPolar 1 ((2*pi)/fromIntegral n) ^ n }}} I still get bad code: {{{ Foo.$wfoo :: GHC.Prim.Int# -> Data.Complex.Complex GHC.Types.Double [GblId, Arity=1, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 225 0}] Foo.$wfoo = \ (ww_s1nN :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.># 1 ww_s1nN) of _ [Occ=Dead] { GHC.Types.False -> letrec { go_a1k0 [Occ=LoopBreaker] :: GHC.Prim.Int# -> Data.Complex.Complex GHC.Types.Double -> Data.Complex.Complex GHC.Types.Double [LclId, Arity=1, Str=DmdType ] go_a1k0 = \ (x_a1k1 :: GHC.Prim.Int#) -> let { v_ayO [Dmd=] :: Data.Complex.Complex GHC.Types.Double [LclId, Str=DmdType] v_ayO = Foo.f (GHC.Types.I# x_a1k1) } in let { ds_dWw [Dmd=] :: Data.Complex.Complex GHC.Types.Double -> Data.Complex.Complex GHC.Types.Double [LclId, Str=DmdType] ds_dWw = case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.==# x_a1k1 ww_s1nN) of _ [Occ=Dead] { GHC.Types.False -> go_a1k0 (GHC.Prim.+# x_a1k1 1); GHC.Types.True -> GHC.Base.id @ (Data.Complex.Complex GHC.Types.Double) } } in \ (z_ayQ :: Data.Complex.Complex GHC.Types.Double) -> ds_dWw (Data.Complex.$fFloatingComplex_$s$c+ z_ayQ v_ayO); } in go_a1k0 1 Foo.foo1; GHC.Types.True -> Foo.foo1 } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 15:58:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 15:58:07 -0000 Subject: [GHC] #8675: make sdist fails in HEAD Message-ID: <047.165bfd4ead06f2f5953dadfb7c1833f5@haskell.org> #8675: make sdist fails in HEAD ------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- make sdist failed on my Linux box with this message: {{{ mv sdistprep/ghc/ghc-7.7.20140117/utils/genprimopcode///Parser.y sdistprep/ghc/ghc-7.7.20140117/utils/genprimopcode///Parser.y.source "cp" utils/haddock/dist/build/Haddock/Lex.hs sdistprep/ghc/ghc-7.7.20140117/utils/haddock/src/Haddock cp: cannot stat ?utils/haddock/dist/build/Haddock/Lex.hs?: No such file or directory make[1]: *** [sdist-ghc-prep] Error 1 make: *** [sdist] Error 2 }}} My last successful make sdist was on January 12th. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 16:07:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 16:07:27 -0000 Subject: [GHC] #8628: dynCompileExpr breaks repeated runDecls of the same name In-Reply-To: <049.09ea66098fe70379109ad292dc66392d@haskell.org> References: <049.09ea66098fe70379109ad292dc66392d@haskell.org> Message-ID: <064.86afb4ebafa109a306fb9ebaeae94d6e@haskell.org> #8628: dynCompileExpr breaks repeated runDecls of the same name -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T8628 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by agibiansky): Simon, The same thing happens with `setContext` instead of `dynCompileExpr`. Does the fix correct that issue as well? (And do you know how I might work around this in the meantime? Is there something else I can use instead of `setContext`, or modify the `setContext` source somehow, to make it work?) Andrew -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 16:18:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 16:18:55 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.1eb9337e98ee9d3dfee8007ee36cf64f@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): So, this is what we want to happen, somehow. We want to transform code of the form {{{ let f = ? x. let h = f (g1 x) in ? y... h (g2 y) ... in ...f 1 2..... f 3 4 ... }}} into {{{ let f = ? x y. let h = f (g1 x) in ... h (g2 y) ... in ...f 1 2..... f 3 4 ... }}} If `g1` is cheap, this is already done (see `[Arity analysis]` in `CoreArity`). But in order to implement `foldl` in terms of `foldr` and get list fusion for it (which would be nice), this needs to work also when `g1` is expensive. In a slightly more general setting, the transformation would not be ok, e.g. in {{{ let f = ? x. let h = f (g1 x) in ? y... h (g2 y) ... in ...map (f 1).... }}} or {{{ let f = ? x. let h = f (g1 x) in ? y... map h... in ...f 1 2..... f 3 4 ... }}} because the expensive `g1` would no longer be shared. So we want an analysis that * looks at the call-sites of `f` * notices that the demand put on `f` from the body of the let, `C(C?(S))`, is actually better than the vanilla demand `C(S)`, * makes sure that with this demand put on `f`, its definition (the rhs) now also has this demand (i.e. no sharing lost in the right hand sid), * uses this to mark the `? y` as one-shot, which will presumably allow the desired optimization. The demand analyser currently analyses the function before the body. One could do a second round, but there is a risk of exponential blow-up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 16:26:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 16:26:54 -0000 Subject: [GHC] #8628: dynCompileExpr breaks repeated runDecls of the same name In-Reply-To: <049.09ea66098fe70379109ad292dc66392d@haskell.org> References: <049.09ea66098fe70379109ad292dc66392d@haskell.org> Message-ID: <064.86bdaba2d5765cd4e8d4fea90c7ee0a4@haskell.org> #8628: dynCompileExpr breaks repeated runDecls of the same name -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T8628 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I think so, but we won't know for sure until we try it. Maybe you can try? I don't know what a good workaround might be. I'm expecting a release candidate for 7.8 any day now, so you can use that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 16:32:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 16:32:25 -0000 Subject: [GHC] #8628: dynCompileExpr breaks repeated runDecls of the same name In-Reply-To: <049.09ea66098fe70379109ad292dc66392d@haskell.org> References: <049.09ea66098fe70379109ad292dc66392d@haskell.org> Message-ID: <064.601502deb7c9ca166aa5a8993d8e8002@haskell.org> #8628: dynCompileExpr breaks repeated runDecls of the same name -------------------------------------+------------------------------------ Reporter: agibiansky | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T8628 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by agibiansky): Alright, thanks. Looking at the source it seems like the same issue, as it uses `icPlusGblRdrEnv`. I'll try it on 7.8 RC when it's out, I guess. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 16:50:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 16:50:01 -0000 Subject: [GHC] #8675: make sdist fails in HEAD In-Reply-To: <047.165bfd4ead06f2f5953dadfb7c1833f5@haskell.org> References: <047.165bfd4ead06f2f5953dadfb7c1833f5@haskell.org> Message-ID: <062.faf958fc63c6cac22e59333b3e6fd4a0@haskell.org> #8675: make sdist fails in HEAD -------------------------------------+------------------------------------ Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"e4a4abae21d14a6c1a4ae875fa582e2b389dc177/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e4a4abae21d14a6c1a4ae875fa582e2b389dc177" Fix #8675 Haddock no longer has a generated parser, so we don't need it in the sdist and we certainly don't want to check for it in the ./configure script (as that would be bogus.) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 16:50:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 16:50:20 -0000 Subject: [GHC] #8675: make sdist fails in HEAD In-Reply-To: <047.165bfd4ead06f2f5953dadfb7c1833f5@haskell.org> References: <047.165bfd4ead06f2f5953dadfb7c1833f5@haskell.org> Message-ID: <062.e8ec64b56a9cb5f8ded47a1e783a094e@haskell.org> #8675: make sdist fails in HEAD -------------------------------------+------------------------------------ Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Thanks for the report. This should be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 16:51:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 16:51:08 -0000 Subject: [GHC] #8676: RTS headers don't compile as C++ Message-ID: <048.04d7458bcdc455548819fc24b2b0b0f2@haskell.org> #8676: RTS headers don't compile as C++ ----------------------------------+---------------------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- GHC's RTS headers can't be included from C++, as they contain constructs like this {{{ dbl_link_replace(bdescr *new, bdescr *old, bdescr **list) }}} (notice the 'new'). This is the case for the headers shipped with 7.6.3 and still seems to be in the HEAD version. Since the code has the usual {{{ #ifdef __cplusplus extern "C" { #endif }}} all over the place, I assume the C++ incompatibility is simply an oversight? In any case, it would seem highly unusual to have a C interface that can't be consumed from C++. It seems all the incompatibilities could be removed with at worst a small amount of inconvenience, and automatic checking for C++ compatibility on each build could be added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 17:39:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 17:39:30 -0000 Subject: [GHC] #7619: Make worker-wrapper unbox data families In-Reply-To: <043.9a9cbf73fd9ff41b12f7d52a16c9328d@haskell.org> References: <043.9a9cbf73fd9ff41b12f7d52a16c9328d@haskell.org> Message-ID: <058.79076f6adefd409e1705d3533e32678e@haskell.org> #7619: Make worker-wrapper unbox data families -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: type family Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): This is actually simple to implement (see [a1ddb71/ghc] on branch `wip/T7619`), but rather ugly due to the additional passing of the FamInstEnv everywhere. That?s why I did not push to master yet. There are types `FamInstEnvs` and `FamInstEnv`, but it is not well- explained, only {{{ type FamInstEnvs = (FamInstEnv, FamInstEnv) -- External package inst-env, Home-package inst-env }}} Note that `topNormaliseType_maybe` takes a `FamInstEnvs`, and I can get a `FamInstEnv` from the `ModGuts` and from `ExternalPackageState`. If I combine these as follows, am I doing the right thing? {{{ doPassDFU :: (DynFlags -> FamInstEnvs -> UniqSupply -> CoreProgram -> CoreProgram) -> ModGuts -> CoreM ModGuts doPassDFU do_pass guts = do dflags <- getDynFlags us <- getUniqueSupplyM hsc_env <- getHscEnv eps <- liftIO $ hscEPS hsc_env let fam_envs = (eps_fam_inst_env eps, mg_fam_inst_env guts) doPass (do_pass dflags fam_envs us) guts }}} And why do we need to make that distinction in the first place ? it seems that `topNormaliseType_maybe` does not treat them differently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 18:12:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 18:12:04 -0000 Subject: [GHC] #7619: Make worker-wrapper unbox data families In-Reply-To: <043.9a9cbf73fd9ff41b12f7d52a16c9328d@haskell.org> References: <043.9a9cbf73fd9ff41b12f7d52a16c9328d@haskell.org> Message-ID: <058.12ba9c02015e6f16ab5fa873be9061d0@haskell.org> #7619: Make worker-wrapper unbox data families -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: type family Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): The package inst-env get extended by a kind of side effect when we lad new modules. The home-package inst env doesn't. You could combine them into one and pass one instead of a pair, but not much would be gained, and there'd be some extra computation to build the combined env that might only be interrogated once. Nothing deep -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 17 23:45:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Jan 2014 23:45:22 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.eac0fa7499d0b0e599614e6bd96476a2@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Small status update: My work on nested CPR has now reached somewhat conclusive state. The performance changes are not great, but it is still nice to have, especially if users who would re-write their code for performance would no longer have to do so. It should not go in for 7.8 ? the gains are too small, and there still might be corner cases bugs. So I plan to merge it somewhen after 7.8. Until then, the branch `wip/nested-cpr` contains the changes in mostly cleaned-up, individually validated patches. I might occasionally rebase that branch to keep the conflicts small. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 02:07:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 02:07:59 -0000 Subject: =?utf-8?q?=5BGHC=5D_=238677=3A_Perhaps_you_haven=27t_installed_t?= =?utf-8?q?he_=22p=5Fdyn=22_libraries_for_package_=E2=80=9Bintege?= =?utf-8?b?ci1nbXDigJk=?= Message-ID: <044.6132243068a2d94d675acf18884e3da4@haskell.org> #8677: Perhaps you haven't installed the "p_dyn" libraries for package ?integer- gmp? -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Compiling ghc from git HEAD (e4a4abae21d14a6c1a4ae875fa582e2b389dc177) with a pretty standard mk/build.mk {{{ > diff mk/build.mk mk/build.mk.sample 12c12 < BuildFlavour = perf --- > #BuildFlavour = perf }}} Once I install ghc-7.7 and try to use cabal to install other libraries I get: {{{ Building aeson-0.7.0.0... Failed to install aeson-0.7.0.0 Last 10 lines of the build log ( /home/erikd/.cabal/logs/aeson-0.7.0.0.log ): [ 9 of 12] Compiling Data.Aeson.Encode ( Data/Aeson/Encode.hs, dist/build/Data/Aeson/Encode.o ) [10 of 12] Compiling Data.Aeson.Generic ( Data/Aeson/Generic.hs, dist/build/Data/Aeson/Generic.o ) [11 of 12] Compiling Data.Aeson ( Data/Aeson.hs, dist/build/Data/Aeson.o ) [12 of 12] Compiling Data.Aeson.TH ( Data/Aeson/TH.hs, dist/build/Data/Aeson/TH.o ) [ 1 of 12] Compiling Data.Aeson.Types.Internal ( Data/Aeson/Types/Internal.hs, dist/build/Data/Aeson/Types/Internal.p_o ) Top level: Failed to load interface for ?GHC.Integer.Type? Perhaps you haven't installed the "p_dyn" libraries for package ?integer-gmp?? Use -v to see a list of the files searched for. Updating documentation index /home/erikd/.cabal/share/doc/index.html cabal: Error: some packages failed to install: aeson-0.7.0.0 failed during the building phase. The exception was: ExitFailure 1 }}} My cabal setup has: {{{ library-profiling: True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 02:32:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 02:32:33 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238677=3A_Perhaps_you_haven=27t_insta?= =?utf-8?q?lled_the_=22p=5Fdyn=22_libraries_for_package_=E2=80=9B?= =?utf-8?q?integer-gmp=E2=80=99?= In-Reply-To: <044.6132243068a2d94d675acf18884e3da4@haskell.org> References: <044.6132243068a2d94d675acf18884e3da4@haskell.org> Message-ID: <059.53668225903e1f24fc0ffa79180023db@haskell.org> #8677: Perhaps you haven't installed the "p_dyn" libraries for package ?integer- gmp? --------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+---------------------------------- Comment (by erikd): Disabling library-profiling avoids the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 02:36:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 02:36:52 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238677=3A_Perhaps_you_haven=27t_insta?= =?utf-8?q?lled_the_=22p=5Fdyn=22_libraries_for_package_=E2=80=9B?= =?utf-8?q?integer-gmp=E2=80=99?= In-Reply-To: <044.6132243068a2d94d675acf18884e3da4@haskell.org> References: <044.6132243068a2d94d675acf18884e3da4@haskell.org> Message-ID: <059.311c9fbd2c878e67b7606c5b1a995d60@haskell.org> #8677: Perhaps you haven't installed the "p_dyn" libraries for package ?integer- gmp? --------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+---------------------------------- Comment (by carter): So is this a GHC problem, or a cabal problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 08:23:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 08:23:47 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238677=3A_Perhaps_you_haven=27t_insta?= =?utf-8?q?lled_the_=22p=5Fdyn=22_libraries_for_package_=E2=80=9B?= =?utf-8?q?integer-gmp=E2=80=99?= In-Reply-To: <044.6132243068a2d94d675acf18884e3da4@haskell.org> References: <044.6132243068a2d94d675acf18884e3da4@haskell.org> Message-ID: <059.3f7f1ddeb809e597122115823ea67c72@haskell.org> #8677: Perhaps you haven't installed the "p_dyn" libraries for package ?integer- gmp? --------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+---------------------------------- Comment (by erikd): The cabal build log file: {{{ Component build order: library creating dist/build creating dist/build/autogen Building aeson-0.7.0.0... Preprocessing library aeson-0.7.0.0... Building library... /home/erikd/GHC/7.7/bin/ghc --info /home/erikd/GHC/7.7/bin/ghc --info creating dist/build /home/erikd/GHC/7.7/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-DGENERICS -optP-include -optPdist/build/autogen/cabal_macros.h -package-name aeson-0.7.0.0 -hide-all-packages -package-db dist/package.conf.inplace -package-id attoparsec-0.11.1.0-41c8e6aca2df0303e7fe3000d38cdfe4 -package- id base-4.7.0.0-7045a3b993088c3620448daac451f892 -package-id bytestring-0.10.2.0-95e8565bd73e658f8a04f3c599d39a67 -package-id containers-0.5.4.0-ee93d8bf2d0dbc80d3cd000138873c1d -package-id deepseq-1.3.0.2-4cd0412e64a1e8bbfd3b43902397eedc -package-id dlist-0.6.0.1-818ad41c2ba39286af31a3187d6f5e93 -package-id ghc- prim-0.3.1.0-f34dd3e2fe06f1014ab1ab7da9096f19 -package-id hashable-1.2.1.0-e936d46f7d359acc8e35d15529c3295a -package-id mtl-2.1.2-6444f48cdf94b59c5c94d8d5b22eafb8 -package-id old- locale-1.0.0.6-7f7810d13b50a4e0ba71391410f0a13e -package-id scientific-0.2.0.1-bfb7d6fb06d533734666bf8460c53ef6 -package-id syb-0.4.1-fb6503ac7b51223a59b3e65579dd917c -package-id template- haskell-2.9.0.0-ffa751fe9632ccbba485bb7d6ace9922 -package-id text-1.0.0.1-f3bf9304c38c5d92eaac0b97e91e3a30 -package-id time-1.4.1-a432da9826cf5bd9c6491b0dd1bdc1b6 -package-id unordered- containers-0.2.3.3-3422d4ad45dca90c87dd33dd50eb27da -package-id vector-0.10.9.1-da9f65c706553d09408a712416bc6459 -XHaskell98 Data.Aeson Data.Aeson.Encode Data.Aeson.Generic Data.Aeson.Parser Data.Aeson.Types Data.Aeson.TH Data.Aeson.Functions Data.Aeson.Parser.Internal Data.Aeson.Types.Class Data.Aeson.Types.Instances Data.Aeson.Types.Internal Data.Aeson.Types.Generic -O2 -Wall [ 1 of 12] Compiling Data.Aeson.Types.Internal ( Data/Aeson/Types/Internal.hs, dist/build/Data/Aeson/Types/Internal.o ) [ 2 of 12] Compiling Data.Aeson.Types.Class ( Data/Aeson/Types/Class.hs, dist/build/Data/Aeson/Types/Class.o ) [ 3 of 12] Compiling Data.Aeson.Functions ( Data/Aeson/Functions.hs, dist/build/Data/Aeson/Functions.o ) [ 4 of 12] Compiling Data.Aeson.Types.Instances ( Data/Aeson/Types/Instances.hs, dist/build/Data/Aeson/Types/Instances.o ) [ 5 of 12] Compiling Data.Aeson.Types.Generic ( Data/Aeson/Types/Generic.hs, dist/build/Data/Aeson/Types/Generic.o ) [ 6 of 12] Compiling Data.Aeson.Types ( Data/Aeson/Types.hs, dist/build/Data/Aeson/Types.o ) [ 7 of 12] Compiling Data.Aeson.Parser.Internal ( Data/Aeson/Parser/Internal.hs, dist/build/Data/Aeson/Parser/Internal.o ) [ 8 of 12] Compiling Data.Aeson.Parser ( Data/Aeson/Parser.hs, dist/build/Data/Aeson/Parser.o ) [ 9 of 12] Compiling Data.Aeson.Encode ( Data/Aeson/Encode.hs, dist/build/Data/Aeson/Encode.o ) [10 of 12] Compiling Data.Aeson.Generic ( Data/Aeson/Generic.hs, dist/build/Data/Aeson/Generic.o ) [11 of 12] Compiling Data.Aeson ( Data/Aeson.hs, dist/build/Data/Aeson.o ) [12 of 12] Compiling Data.Aeson.TH ( Data/Aeson/TH.hs, dist/build/Data/Aeson/TH.o ) /home/erikd/GHC/7.7/bin/ghc --make -fbuilding-cabal-package -O -prof -osuf p_o -hisuf p_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-DGENERICS -optP-include -optPdist/build/autogen/cabal_macros.h -package-name aeson-0.7.0.0 -hide- all-packages -package-db dist/package.conf.inplace -package-id attoparsec-0.11.1.0-41c8e6aca2df0303e7fe3000d38cdfe4 -package-id base-4.7.0.0-7045a3b993088c3620448daac451f892 -package-id bytestring-0.10.2.0-95e8565bd73e658f8a04f3c599d39a67 -package-id containers-0.5.4.0-ee93d8bf2d0dbc80d3cd000138873c1d -package-id deepseq-1.3.0.2-4cd0412e64a1e8bbfd3b43902397eedc -package-id dlist-0.6.0.1-818ad41c2ba39286af31a3187d6f5e93 -package-id ghc- prim-0.3.1.0-f34dd3e2fe06f1014ab1ab7da9096f19 -package-id hashable-1.2.1.0-e936d46f7d359acc8e35d15529c3295a -package-id mtl-2.1.2-6444f48cdf94b59c5c94d8d5b22eafb8 -package-id old- locale-1.0.0.6-7f7810d13b50a4e0ba71391410f0a13e -package-id scientific-0.2.0.1-bfb7d6fb06d533734666bf8460c53ef6 -package-id syb-0.4.1-fb6503ac7b51223a59b3e65579dd917c -package-id template- haskell-2.9.0.0-ffa751fe9632ccbba485bb7d6ace9922 -package-id text-1.0.0.1-f3bf9304c38c5d92eaac0b97e91e3a30 -package-id time-1.4.1-a432da9826cf5bd9c6491b0dd1bdc1b6 -package-id unordered- containers-0.2.3.3-3422d4ad45dca90c87dd33dd50eb27da -package-id vector-0.10.9.1-da9f65c706553d09408a712416bc6459 -XHaskell98 Data.Aeson Data.Aeson.Encode Data.Aeson.Generic Data.Aeson.Parser Data.Aeson.Types Data.Aeson.TH Data.Aeson.Functions Data.Aeson.Parser.Internal Data.Aeson.Types.Class Data.Aeson.Types.Instances Data.Aeson.Types.Internal Data.Aeson.Types.Generic -O2 -Wall [ 1 of 12] Compiling Data.Aeson.Types.Internal ( Data/Aeson/Types/Internal.hs, dist/build/Data/Aeson/Types/Internal.p_o ) Top level: Failed to load interface for ?GHC.Integer.Type? Perhaps you haven't installed the "p_dyn" libraries for package ?integer-gmp?? Use -v to see a list of the files searched for. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 08:47:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 08:47:15 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238677=3A_Perhaps_you_haven=27t_insta?= =?utf-8?q?lled_the_=22p=5Fdyn=22_libraries_for_package_=E2=80=9B?= =?utf-8?q?integer-gmp=E2=80=99?= In-Reply-To: <044.6132243068a2d94d675acf18884e3da4@haskell.org> References: <044.6132243068a2d94d675acf18884e3da4@haskell.org> Message-ID: <059.52cc57ada8d9098834bda1b2b1568a1a@haskell.org> #8677: Perhaps you haven't installed the "p_dyn" libraries for package ?integer- gmp? -------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by hvr): * cc: thoughtpolice (added) * failure: Other => None/Unknown * priority: normal => highest * component: libraries (other) => Template Haskell * milestone: => 7.8.1 Comment: Here's the core of the problem, TH wants to use the profiling version of the libraries, when `-prof` is in effect: {{{ $ echo 'main = return ()' > t8677.hs $ ghc --make -prof t8677.hs [1 of 1] Compiling Main ( t8677.hs, t8677.o ) Linking t8677 ... $ ghc -XTemplateHaskell --make -prof t8677.hs [1 of 1] Compiling Main ( t8677.hs, t8677.o ) [flags changed] Top level: Failed to load interface for ?GHC.Integer.Type? Perhaps you haven't installed the "p_dyn" libraries for package ?integer-gmp?? Use -v to see a list of the files searched for. $ ghc -XTemplateHaskell --make t8677.hs [1 of 1] Compiling Main ( t8677.hs, t8677.o ) Linking t8677 ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 10:41:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 10:41:21 -0000 Subject: [GHC] #8678: Derivin `Functor` complains about existential type Message-ID: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> #8678: Derivin `Functor` complains about existential type ------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When deriving a functor with !DataKinds enabled {{{ {-# LANGUAGE DataKinds, DeriveFunctor, FlexibleInstances, GADTs, KindSignatures, StandaloneDeriving #-} data {- kind -} Nat = Z | S Nat data NonStandard :: Nat -> * -> * where Standard :: a -> NonStandard (S n) a Non :: NonStandard n a -> a -> NonStandard (S n) a deriving instance Show a => Show (NonStandard n a) deriving instance Functor (NonStandard n) }}} I get following error message {{{ NonStandard.hs:10:1: Can't make a derived instance of ?Functor (NonStandard n)?: Constructor ?Standard? must not have existential arguments In the stand-alone deriving instance for ?Functor (NonStandard n)? }}} But the `Standard` constructor is not at all existential in the last type argument! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 11:02:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 11:02:33 -0000 Subject: [GHC] #8451: Link problem on FreeBSD In-Reply-To: <052.b8772d44ba9b4118081982759aed2ca1@haskell.org> References: <052.b8772d44ba9b4118081982759aed2ca1@haskell.org> Message-ID: <067.c64d49167a066eda67caeaa938a14e50@haskell.org> #8451: Link problem on FreeBSD --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: pgj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Gabor Pali ): In [changeset:"1ad599ea241626f47006fa386e4aaf38dc91fdbb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1ad599ea241626f47006fa386e4aaf38dc91fdbb" Fix #8451 On FreeBSD, /usr/lib has to be added to the library path on linking when libthr is needed but -nostdlib is used (which is the case when the -prof and -threaded flags are combined). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 11:22:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 11:22:19 -0000 Subject: [GHC] #8451: Link problem on FreeBSD In-Reply-To: <052.b8772d44ba9b4118081982759aed2ca1@haskell.org> References: <052.b8772d44ba9b4118081982759aed2ca1@haskell.org> Message-ID: <067.646cf1c8bd5244b602e68cb6a193251d@haskell.org> #8451: Link problem on FreeBSD --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: pgj Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by pgj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 11:27:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 11:27:04 -0000 Subject: [GHC] #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi In-Reply-To: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> References: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> Message-ID: <057.2fcb2847ba5d7ae8c53cc564ec55231a@haskell.org> #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi -------------------------------+------------------------------------ Reporter: pgj | Owner: pgj Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Comment (by pgj): Hm, it seems this is not required anymore since setting `DYNAMIC_GHC_PROGRAMS=YES` as default for FreeBSD too solves it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 11:33:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 11:33:16 -0000 Subject: [GHC] #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi In-Reply-To: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> References: <042.c71c0fc83010a14dadf11ed6c7cfbe83@haskell.org> Message-ID: <057.532181511e9f77cc2c77b8e9c87cc784@haskell.org> #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi -------------------------------+------------------------------------ Reporter: pgj | Owner: pgj Type: task | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Changes (by pgj): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 12:05:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 12:05:27 -0000 Subject: [GHC] #8679: Extend FunD data constructor with information about type signature Message-ID: <048.78fce9f4f7494f1d23d03eb05a55ec10@haskell.org> #8679: Extend FunD data constructor with information about type signature ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I want to propose that `FunD` data constructor in Template Haskell is extended with a field that contains that function's type signature (if present). Currently the type signature is a separate declaration represented with `SigD`. I motivate my proposal with the fact that function and its type signature are not independent and it might be the case that processing one requires knowledge of the other. Here's a concrete example. Recently I've been working together with Richard Eisenberg on promoting higher-order functions to the type level. To promote a higher order function I need to replace applications of a function passed as a parameter with usage of a special `Apply` type family. For example the definition of `map`: {{{ map :: (a -> b) -> [a] -> [b] map _ [] = [] map f (x:xs) = f x : map f xs }}} will be promoted to: {{{ type family Map (f :: (TyFun k1 k2) -> *) (list :: [k1]) :: [k2] where Map f '[] = '[] Map f (x ': xs) = Apply f x ': Map f xs }}} To generate equations in the `Map` type family from declarations stored by a `FunD` data constructor I need to know that `f` is a function. The only way for me to know this is by promoting type signature stored in `SigD` and checking the type of `f`. But to promote type signature to a type family I need to know the number of patterns in a function clause, which again is stored in `FunD`. In other words my algorithm looks like this: 1. Recover number of patterns in a function clause 2. Based on number of paterns in function's clause promote the type signature to a type family 3. Based on promoted type signature and definitions in `FunD` generate equations in the type family. Since `FunD` and `SigD` are independent I need to do three separate passes (or two passes + some hacking). If `FunD` contained informatuon about type signature I could achieve the same in one pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 15:43:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 15:43:02 -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.a520293580bca8637150aa3d5deda147@haskell.org> #7775: Mark intentionally omitted type class instances --------------------------------------------+------------------------------ Reporter: Lemming | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: wontfix | Keywords: instance Operating System: Unknown/Multiple | warning Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by Lemming): * version: 7.6.2 => 7.7 Comment: There is still a difference between intentionally and unintentionally omitted instances. I find it important to document for me and for others why I have omitted an instance. Also without the "possible fix" message people keep asking why an obvious instance is missing. "Why is this parser not Monoid?" - maybe because there are different ways of viewing it as Monoid. "Why is this identifier type not Num?" - maybe because it makes no sense to multiply identifiers. Or even worse, people do not just ask but start writing (conflicting) orphan instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 18:01:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 18:01:49 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.636991a5f9dfdf92f25bbfdc3dbc4212@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): Replying to [comment:10 carter]: > did you try doing a specialize on > > (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) > > without the class constraint? If I remove the constraint, the specialization occurs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 19:52:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 19:52:30 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.e76cde25a8de6feb282e49fa0284f2a1@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by carter): do you get the desired specialization behavior now? If so, i suppose that means maybe theres need for clearer support tooling around understanding specialization pragmas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 19:59:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 19:59:49 -0000 Subject: [GHC] #8678: Derivin `Functor` complains about existential type In-Reply-To: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> References: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> Message-ID: <063.5a6207d606054cadbeb0e0536b367504@haskell.org> #8678: Derivin `Functor` complains about existential type -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): where does the variable {{{n}}} get introduced in {{{Standard :: a -> NonStandard (S n) a}}} ? That seems existential -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 20:44:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 20:44:24 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.498bc0228cd6d12d952fba0fb1a399d4@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): Replying to [comment:12 carter]: > do you get the desired specialization behavior now? > > If so, i suppose that means maybe theres need for clearer support tooling around understanding specialization pragmas? No, I need the specialization to fire ''with'' the constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 20:53:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 20:53:54 -0000 Subject: [GHC] #8678: Derivin `Functor` complains about existential type In-Reply-To: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> References: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> Message-ID: <063.2871b15b3845f9892343ff2eb92dd135@haskell.org> #8678: Derivin `Functor` complains about existential type -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by heisenbug): Replying to [comment:1 carter]: > where does the variable {{{n}}} get introduced in {{{Standard :: a -> NonStandard (S n) a}}} ? That seems existential No, it is a variable that appears in the type of the result, so it is not existential. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 21:32:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 21:32:04 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.c682fb493991efd3a181709bb4ba6478@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by carter): why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 21:33:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 21:33:34 -0000 Subject: [GHC] #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction Message-ID: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction ------------------------------+-------------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I'm sorry if this is expected behavior; I'm still trying to wrap my head around this. I was surprised to learn that the right branch of an `orElse` can be invalidated by changes to the world only visible by the left branch. This might lead to starvation or performance issues for the use- case I was envisioning it for (e.g. several threads trying to take from one of a large set of TMVars in a randomized round-robin fashion). Here is a really bad example demonstrating current behavior: {{{ import Control.Concurrent import Control.Concurrent.STM import Control.Concurrent.STM.TSem import Control.Monad import System.IO import Debug.Trace main = do hSetBuffering stdout NoBuffering noMansLand <- replicateM 998 $ newTVarIO 0 t0 <- newTVarIO (1::Int) t999 <- newTVarIO (-1) let ts = t0:noMansLand++[t999] done <- atomically $ newTSem 0 forkIO $ atomically $ nestedOrElseMap done ts -- need enough time here for nestedOrElseMap thread above to move past t0 -- in this version, the modifications to t0 force nestedOrElseMap to be restarted forkIO (trace "starting vexing!" $ forever $ atomically $ (modifyTVar' t0 (+1) >> trace "vex" (return ()))) -- in this version nestedOrElseMap causes this transaction to be restarted and never makes progress: --forkIO (atomically (trace "starting vexing!" $ forever $ (modifyTVar' t0 (+1) >> trace "vex" (return ())))) atomically $ waitTSem done putStrLn "No livelock! Did the t0 counter get incremented?: " atomically (readTVar t0) >>= print -- another thread begins modifying head ts after we've moved to the right branch nestedOrElseMap :: TSem -> [TVar Int] -> STM () nestedOrElseMap done ts = trace "nestedOrElseMap starting" $ foldl1 orElse $ map transaction $ zip [(1::Int)..] ts where transaction (cnt,v) = do n <- traceShow cnt $ readTVar v if n < 0 then trace "@" (modifyTVar' v (subtract 1)) >> signalTSem done else retry }}} I can see it possibly being useful that both branches of an `orElse` see the same view of the variables they ''share'', but current behavior seems overzealous in restarting the whole transaction. Maybe this is an artifact of changes related to #7493? Or maybe it's obvious why this behavior has to be the way it is and its just not clicking for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 21:35:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 21:35:24 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.9d45b1df47dca34d184bd00b3b2f7b87@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by carter): could you walk me through why {{{ {-# SPECIALIZE plusFastCyc :: (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) #-} }}} isn't satisfactory? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 21:52:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 21:52:24 -0000 Subject: [GHC] #6135: Unboxed Booleans In-Reply-To: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> References: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> Message-ID: <058.fc53310ddab5e867dfcf5ec15b1dd57d@haskell.org> #6135: Unboxed Booleans ---------------------------------------------+----------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: primops/should_run/T6135 | Difficulty: Unknown Blocking: | Blocked By: 8103, | 8103 | Related Tickets: #605 ---------------------------------------------+----------------------------- Comment (by Lemming): Btw. LLVM usually represents boolean values by type `i1`. It would certainly be easier to translate `Bool#` to `i1`, than translating `Int#` to `i1` in a special case. But as I understand the `Bool#` type was finally rejected in order to optimize all enumeration types the same way, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 21:54:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 21:54:29 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.899d7434b6027c7f02bc6c8a3c7525ab@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): A post on #8672 seems more relevant here: Simon PJ says: Richard, two questions. First (Q1), can't a data instance have a representational role inferred? Eg this ought to work. The definition of `g` is currently rejected. {{{ data family T a data instance T [b] = MkT b newtype Age = MkAge Int g :: T [Age] -> T [Int] g x = coerce x }}} Second question (Q2). Are role annotations allowed on data family declarations, where they could indicate which parameters are the indices: {{{ type role T representational nominal -- Only second param can be an index data family T a b data instance T a Bool = ... -- Allowed data instance T Bool b = ... -- Rejected }}} (And similarly for type families.) Similarly are role annotations allowed on data instance declarations, where they would be useful in exactly the same way that they are on data decls {{{ data family T a type role T [a] (a:nominal) data instance T [a] = MkT a }}} Here we are running out of syntax! This isn't supported now because I think all parameters are automatically nominal (see Q1 for why they shouldn't be). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 22:01:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 22:01:11 -0000 Subject: [GHC] #6135: Unboxed Booleans In-Reply-To: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> References: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> Message-ID: <058.551d9a51a90fa7f4389c11c34effc337@haskell.org> #6135: Unboxed Booleans ---------------------------------------------+----------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: primops/should_run/T6135 | Difficulty: Unknown Blocking: | Blocked By: 8103, | 8103 | Related Tickets: #605 ---------------------------------------------+----------------------------- Comment (by carter): @lemming, Bool# is now Int# afaik, could you explain what you mean? even if we used a i1 rep, it still needs a full register! So theres no lost for the in register rep to be Int#, afaik -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 22:06:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 22:06:34 -0000 Subject: [GHC] #6135: Unboxed Booleans In-Reply-To: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> References: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> Message-ID: <058.4983eaf7831adab587fb5fa8e6af2bd9@haskell.org> #6135: Unboxed Booleans ---------------------------------------------+----------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: primops/should_run/T6135 | Difficulty: Unknown Blocking: | Blocked By: 8103, | 8103 | Related Tickets: #605 ---------------------------------------------+----------------------------- Comment (by Lemming): Replying to [comment:90 carter]: > @lemming, Bool# is now Int# afaik, could you explain what you mean? even if we used a i1 rep, it still needs a full register! So theres no lost for the in register rep to be Int#, afaik `Int#` represents a large range of integers, whereas `i1` in LLVM has only values 0 and 1. That is, LLVM can optimize based on the knowledge of the restricted value set of `i1`, but it certainly fails to do so on `i32` or `i64`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 22:06:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 22:06:40 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.54f6eb970e14f74f3c07556ea335b95c@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * owner: => goldfire Comment: Q1: Yes, that's possible. I didn't do it mostly because my stomach lurched when thinking about parsing role annotation concrete syntax for data family instances -- I was going to wait until someone shouted. I considered having data instances go through role inference without allowing for role annotations, but that meant it would be impossible to create a properly abstract data family instance. Q2: That's possible but currently unimplemented (see earlier posts to this bug report). So, if we could just figure out a decent concrete syntax, I could make it all work. The hardest part will be updating the parser and `HsSyn` stuff. The role inference/checking should be almost no work at all. As a strawman syntax, what about {{{ type role instance T [nominal] }}} for the case above. Note the word `instance` to specify that we're talking about the roles on an instance, not on the family `T`. Then, role names would appear wherever type variables appear in the corresponding instance declaration. Underscores would be supported in these positions, as well (like normal role annotations). The corresponding data (or newtype) instance would have to be in the same module, as usual. The appearance of the word `type` (as opposed to `data`) in the role annotation syntax is regrettable, but it conforms to the universal use of the word `type` in all role annotations. Though it makes me want to cry, I suppose we should allow ''associated'' role instance annotations, in class instance definitions alongside associated data/newtype instances. Does anyone out there actually want to use this feature? Eager users would help motivate all this! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 22:08:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 22:08:48 -0000 Subject: [GHC] #8672: :browse and roles on typefamilies In-Reply-To: <047.79fcde45b99494808022df1c15fe6d9a@haskell.org> References: <047.79fcde45b99494808022df1c15fe6d9a@haskell.org> Message-ID: <062.849d0f79fb07c456de111bd26bf3328f@haskell.org> #8672: :browse and roles on typefamilies -------------------------------------------------+------------------------- Reporter: monoidal | Owner: Type: bug | goldfire Priority: low | Status: new Component: Compiler (Type checker) | Milestone: Resolution: | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): I've moved the conversation about roles on data instances to #8177, where it is more relevant. Please see that ticket for further information. Perhaps this ticket should stay open as a reminder to revisit `:browse` and `:info` if/when data instance role annotations are added. Is there a test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 23:06:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 23:06:05 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.ba71f874aa9e91cc57bf0f1b73727c78@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): @goldfire, conflating list syntax seems red flaggy... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 23:07:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 23:07:51 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.274edaa9cacd89b5c3647e8321951a01@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): that said, having some way of describing these properties seems important, though i'm not sure if i'm sufficiently sophisticated a library author yet to see a use case for myself as yet -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 23:08:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 23:08:34 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.8b193b71fc15b7292d8a9ab022318499@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): But that's the annotation for the instance {{{ data instance T [a] }}} If we had an instance {{{ data instance T (Int, Maybe a) }}} the role annotation would be {{{ type role instance T (Int, Maybe representational) }}} for example. (Though, that particular annotation would be a no-op, as `representational` would be inferred.) I don't believe I'm conflating list syntax here... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 18 23:41:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Jan 2014 23:41:42 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.99f1194c7820e94b54f087a9aa6e3346@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------ Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): you may be right! I'll reread this ticket when i'm a bit more awake :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 04:10:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 04:10:52 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.ad8efd7b109929da6e267de4c81b9add@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): In real code, `plusFastCyc` will call a function in class `Factored`. The function in `Factored` and the call to it in `plusFastCyc` were removed because they weren't needed to demonstrate the specialization problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 07:52:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 07:52:36 -0000 Subject: [GHC] #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction In-Reply-To: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> References: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> Message-ID: <063.2a830c90b09cae3c3fb5422cb11251b9@haskell.org> #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction --------------------------------------------+------------------------------ Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 carter): any chance you could cook up an even smaller example that exhibits the problem? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 11:17:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 11:17:45 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.19f2e15e91852f3661a78ddc047f8bfd@haskell.org> #5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Changes (by cactus): * status: new => patch * milestone: _|_ => 7.8.1 Comment: Code is now past initial review and is ready in the `wip/pattern-synonyms` branch on the GHC Git repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 12:57:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 12:57:52 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.44cfb2cc247f3d9d06632f58dfe8116b@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): I've learned Linker.c a bit further and found that it's entirely possible to use {{{SymbolExtra}}} structure and {{{SymbolExtra *symbol_extras}}} pointer in {{{ObjectCode}}} structure, which are both defined but not used under mingw32 and are used on unixish systems for almost the same purposes. Hence, the question: am I allowed to reuse them in PEi386-related code but in a slightly different way than it is on unixish systems? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 13:45:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 13:45:59 -0000 Subject: [GHC] #8676: RTS headers don't compile as C++ In-Reply-To: <048.04d7458bcdc455548819fc24b2b0b0f2@haskell.org> References: <048.04d7458bcdc455548819fc24b2b0b0f2@haskell.org> Message-ID: <063.6b6dc5097d97c70b480777e41a49569a@haskell.org> #8676: RTS headers don't compile as C++ ----------------------------------------+---------------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"fe3740bd931ca30c22d956816f71be9026eeef54/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fe3740bd931ca30c22d956816f71be9026eeef54" Make `#include "Rts.h"` C++-compatible again (re #8676) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 15:00:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 15:00:52 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.db7ee3177a9a30886fcbc63cf8e2a819@haskell.org> #4012: Compilation results are not deterministic ----------------------------------+---------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 days) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------------+---------------------------------------- Comment (by nh2): Is this related to https://ghc.haskell.org/trac/ghc/ticket/8144, and does its fix maybe improve the situation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 15:01:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 15:01:05 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.9ab459109ea42d0f2bbd18b892306346@haskell.org> #4012: Compilation results are not deterministic ----------------------------------+---------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 days) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------------+---------------------------------------- Changes (by nh2): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 15:05:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 15:05:51 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.f56fa03b62961d8a60d8663a431f9f98@haskell.org> #4012: Compilation results are not deterministic ----------------------------------+---------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 days) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------------+---------------------------------------- Comment (by nomeata): Replying to [comment:39 nh2]: > Is this related to https://ghc.haskell.org/trac/ghc/ticket/8144, and does its fix maybe improve the situation? Not very much, I believe, as the cases discuss here do not necessarily involve header files. But the fix for #8144 is of course a general improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 15:10:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 15:10:06 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.5254354998824739880a7c3b0f9e9c2b@haskell.org> #4012: Compilation results are not deterministic ----------------------------------+---------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 days) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------------+---------------------------------------- Comment (by nh2): Replying to [comment:41 nomeata]: > Not very much, I believe, as the cases discuss here do not necessarily involve header files. But the fix for #8144 is of course a general improvement. It's not so much about header files only - I believe {{{UsageFile}}} can be introduced using multiple ways, not only {{{#include}}}, and maybe some other time staps makes it into those hashes like in that bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 15:37:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 15:37:58 -0000 Subject: [GHC] #8681: Don't disable dynamic linking for LLVM flavours Message-ID: <046.7d00c22f21a52b42f6545d7d4a2e8357@haskell.org> #8681: Don't disable dynamic linking for LLVM flavours ------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- build.mk.sample still disables dynamic linking, despite this configuration now being supported. Fix this. Patch attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 15:38:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 15:38:30 -0000 Subject: [GHC] #8681: Don't disable dynamic linking for LLVM flavours In-Reply-To: <046.7d00c22f21a52b42f6545d7d4a2e8357@haskell.org> References: <046.7d00c22f21a52b42f6545d7d4a2e8357@haskell.org> Message-ID: <061.12c03f57d4c2164b324df492a6875a2e@haskell.org> #8681: Don't disable dynamic linking for LLVM flavours -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 17:17:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 17:17:19 -0000 Subject: [GHC] #8682: GHC compilation bug Message-ID: <044.3e57ec0e7a6d09a2d41c2d1f19a955da@haskell.org> #8682: GHC compilation bug ----------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Description: Attempted to compile a relatively small & simple Haskell program. GHC crashes unpon compilation. Source code in its entirety: import System.Environment data NestedList a = Elem a | List [NestedList a] deriving (read) main = do args <- getArgs print . flatten . read $ concat args flatten :: NestedList a -> [a] flatten Elem x = [x] flatten List x = concatMap flatten x Console Log in it's entirety: user at computer:~/path/to/file/$ ghc -v file.hs Glasgow Haskell Compiler, Version 7.4.1, stage 2 booted by GHC version 7.4.1 Using binary package database: /usr/lib/ghc/package.conf.d/package.cache Using binary package database: /home/user/.ghc/x86_64-linux-7.4.1/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.2.0.0-c2ff696e5b8ec4d4b2bc2e42085fe471 wired-in package integer-gmp mapped to integer- gmp-0.4.0.0-3cccac07aef8e27023f605c1f45bdf74 wired-in package base mapped to base-4.5.0.0-40b99d05fae6a4eea95ea69e6e0c9702 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.7.0.0-8c8cd20e21666657195efabced685fe1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *prob07.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Sun Jan 19 10:47:44 CST 2014 ms_mod = main:Main, ms_textual_imps = [import (implicit) Prelude, import System.Environment] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file prob07.hs Created temporary directory: /tmp/ghc6732_0 *** Checking old interface for main:Main: [1 of 1] Compiling Main ( prob07.hs, prob07.o ) *** Parser: *** Renamer/typechecker: *** Deleting temp files: Deleting: /tmp/ghc6732_0/ghc6732_0.s Warning: deleting non-existent /tmp/ghc6732_0/ghc6732_0.s *** Deleting temp dirs: Deleting: /tmp/ghc6732_0 ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): nameModule read{tv aaf} 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 Sun Jan 19 18:47:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 18:47:35 -0000 Subject: [GHC] #8682: GHC compilation bug In-Reply-To: <044.3e57ec0e7a6d09a2d41c2d1f19a955da@haskell.org> References: <044.3e57ec0e7a6d09a2d41c2d1f19a955da@haskell.org> Message-ID: <059.b3bcae07f8ae6150ad3cfa7589555fbe@haskell.org> #8682: GHC compilation bug ---------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by monoidal): This is already fixed in GHC 7.6: #5961. In your code "deriving (read)" should be "deriving (Read)". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 18:47:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 18:47:46 -0000 Subject: [GHC] #8682: GHC compilation bug In-Reply-To: <044.3e57ec0e7a6d09a2d41c2d1f19a955da@haskell.org> References: <044.3e57ec0e7a6d09a2d41c2d1f19a955da@haskell.org> Message-ID: <059.f910ca5a8f3a1a204bcd16ce47df1937@haskell.org> #8682: GHC compilation bug ---------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 19:24:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 19:24:31 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.cf69d18a2b179fd229bcde8ce03624be@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): has there been any progress on this branch? wheres the activity / dev work been? https://github.com/scpmw/ghc/commits/profiling-ncg ? or where? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 19:29:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 19:29:13 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file Message-ID: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- so theres a pretty clear consensus that we need to move away from using our c compiler for CPP, so should we add that info to the settings file? I propose adding the following fields to the settings file: "use c compiler cpp", which can have either "YES" or "NO". If "YES", the settings file indicated C compiler is used unless the c compiler selection is overrided by ghc at runtime via -pgmc or -pgmp(p?) if "NO", then the "cpp program" and "cpp program options" fields would be used, unless overridden by -pgmp there'd be some associated patched in the compiler/main/DriverPipeline.hs too i think, but relatively minimal. this would make it much easier to distributed a GHC with its own CPP tool that works -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 20:37:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 20:37:39 -0000 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> Message-ID: <061.2cfe5d0c9bd45ea1d71ca5055be1f761@haskell.org> #367: Infinite loops can hang Concurrent Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler Operating System: Unknown/Multiple | allocation Type of failure: Incorrect result | Architecture: Unknown/Multiple at runtime | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by nh2): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 20:42:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 20:42:02 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.27135538966d946b1760c219e85875f1@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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 Tarrasch): Hi Carter, Implementing stack traces can be thought of two parts, (1) the code- generator stuff that now has to be able to also emit debug data and (2) Library and rts components. Peter is working on the (1)-part, his most recent work is here[1] (afaict). I work on the (2)-side of things. My work is here[2]. But I think the most interesting parts is the research and conversations we're having. Peter and I are usually collaborating at least weekly on this. I'll be more than happy to share or explain any detail you might be interested in. [1]: https://github.com/scpmw/ghc/tree/profiling-import [2]: https://github.com/Tarrasch/ghc/tree/dev (I just pushed this, good thing you reminded me) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 19 23:56:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Jan 2014 23:56:10 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix Message-ID: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://hackage.haskell.org/package/base-4.6.0.1/docs/System-Timeout.html claims that {{{timeout}}} can interrupt {{{hWaitForInput}}}, but in fact that's false (e.g. mentioned in https://ghc.haskell.org/trac/ghc/ticket/7353#comment:4). {{{ -- import Control.Concurrent import System.IO import System.Timeout main = timeout (1 * 1000000) $ hWaitForInput stdin (5 * 1000) }}} will not be killed after 1 second, but instead wait for the full 5 seconds timeout passed to {{{hWaitForInput}}}. The implementation is {{{ready}}} at http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO- FD.html, where we have two foreign calls: {{{safe fdReady}}} and {{{unsafe unsafe_fdReady}}}. The actual C implementation is at https://github.com/haskell- suite/base/blob/master/cbits/inputReady.c#L16. It uses {{{select}}} on Unix, and does check for {{{EINTR}}}, so I believe that according to http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/ffi.html#ffi- interruptible both foreign calls can be replaced by a single {{{interruptible}}} one. Is that true? If not, it's a documentation bug in {{{timeout}}} at least. Also, does {{{interruptible}}}, apart from allowing the function to be interrupted, behave more like {{{safe}}} or {{{unsafe}}}? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 00:08:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 00:08:17 -0000 Subject: [GHC] #7216: Compositional blocking on file descriptors In-Reply-To: <053.7fd2b35c5565f098286f6b67aaa1bc6e@haskell.org> References: <053.7fd2b35c5565f098286f6b67aaa1bc6e@haskell.org> Message-ID: <068.29d8aabc57c5c159f5d820e5b98b2be5@haskell.org> #7216: Compositional blocking on file descriptors -------------------------------------+------------------------------------ Reporter: AndreasVoellmy | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by twhitehead): It seems a bit strange that the last patch re-implemented different versions of threadWait{Read,Write}STM in Control.Concurrent for Windows (mingw32_HOST_OS) despite the GHC.Conc versions covering both Windows and non-Windows. Why not just Control.Concurrent.threadWaitReadSTM :: Fd -> IO (STM (), IO ()) Control.Concurrent.threadWaitReadSTM = GHC.Conc.threadWaitReadSTM Control.Concurrent.threadWaitWriteSTM :: Fd -> IO (STM (), IO ()) Control.Concurrent.threadWaitWriteSTM = GHC.Conc.threadWaitWriteSTM If the issue is the GHC.Conc versions for Windows are deficient (e.g., they don't handle [pass along] threadWait{Read,Write} exceptions), shouldn't they be fixed instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 03:50:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 03:50:21 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.c29b753dacd7aeecdc5149ed19bc0084@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by Andrea): Replying to [comment:33 thoughtpolice]: > Furthermore I can't find the source code for `pthread_getspecific` & co, so it's impossible to check if my 10.8 fix still works OK. The most recent `pthread_getspecific` source released by Apple was part of Libc-825.40.1. You can find it here: http://www.opensource.apple.com/source/Libc/Libc-825.40.1/x86_64/pthreads/pthread_getspecific.s Following Libc-825.40.1 Apple released the source for Libc-997.1.1 but the `pthread_getspecific` code is missing (they forgot it: http://lists.apple.com/archives/darwin-dev/2013/Nov/msg00002.html). I'm not an uber expert but TLS seems now to be working very similarly to how it works on other unixes and therefore it's unlikely that there has been any further change to `pthread_getspecific`. So maybe an inline function (like the `_pthread_getspecific_direct` in comment 13) can now be used with a key from 'pthread_key_create' without stealing a predefined slot. Recommendations in comment 16 by simonmar would still apply, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 06:27:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 06:27:58 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.364da7ea0353aaa53f730d252da3869d@haskell.org> #3919: Or-patterns as GHC extension -------------------------------------+------------------------------------ Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by lpsmith): * cc: leon.p.smith@? (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 10:14:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 10:14:17 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.b5bcb731659969f1c9451038448599a7@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by simonmar): Replying to [comment:38 awson]: > Edit: > Perhaps, reusing {{{SymbolExtra *symbol_extras}}} pointer in {{{ObjectCode}}} structure is not such a good idea, because in current code {{{lookupSymbol}}} is used in haskell object-linking code and calls {{{lookupSymbolInDLLs}}} directly. Thus we probably should make a trampoline for every "far" symbol, imported from DLL, as is now in my patch. I don't understand this, could you explain more? Surely it should be fine to return a 64-bit pointer from `lookupSymbol`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 10:16:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 10:16:38 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.16bb2591d98bd57dd8ff56dd6bc061f5@haskell.org> #4012: Compilation results are not deterministic ----------------------------------+---------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 days) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------------+---------------------------------------- Comment (by simonmar): Things got worse for a while when we were including timestamps in the interface, but then #8144 fixed that. There are still a set of underlying problems that cause non-determinism. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 11:44:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 11:44:03 -0000 Subject: [GHC] #7619: Make worker-wrapper unbox data families In-Reply-To: <043.9a9cbf73fd9ff41b12f7d52a16c9328d@haskell.org> References: <043.9a9cbf73fd9ff41b12f7d52a16c9328d@haskell.org> Message-ID: <058.ea2dcba56fa93456cbd6c190d8670f1c@haskell.org> #7619: Make worker-wrapper unbox data families -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: type family Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"2bb19fad1d809dda37011f442b0fd561aea045b6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2bb19fad1d809dda37011f442b0fd561aea045b6" Make worker-wrapper unbox data families by passing the FamInstEnvs all the way down. This closes #7619. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 11:44:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 11:44:46 -0000 Subject: [GHC] #7619: Make worker-wrapper unbox data families In-Reply-To: <043.9a9cbf73fd9ff41b12f7d52a16c9328d@haskell.org> References: <043.9a9cbf73fd9ff41b12f7d52a16c9328d@haskell.org> Message-ID: <058.66c6809c2fb185cbbee61debefede257@haskell.org> #7619: Make worker-wrapper unbox data families ------------------------------------------+-------------------------------- Reporter: akio | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: type family Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: perf/should_run/T7619 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by nomeata): * status: new => closed * testcase: => perf/should_run/T7619 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 12:28:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 12:28:35 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.7d7d2a59bf419a9b5f58de83dcdd9cc2@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): If we leave {{{lookupSymbol}}} unmodified then "far" symbol, imported from DLL, being accessed through {{{lookupSymbol}}} has different address than being accessed through trampoline. Is this ok? Or do I completely misunderstand the picture? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 13:59:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 13:59:54 -0000 Subject: [GHC] #8685: -split-objs doesn't work for executables Message-ID: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> #8685: -split-objs doesn't work for executables ------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While investigating [this bug report](https://github.com/haskell/cabal/issues/1611), I've noticed that the `-split-objs` option only works for libraries, but not for executables. That is, unlike in the case of libraries, the driver feeds only `A.o B.o ...` files to the linker instead of `A_split_0.o A_split_1.o ... B_split_0.o B_split_1.o ...`. It'd be nice if `-split-objs` could be changed to also work on executables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 14:49:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 14:49:08 -0000 Subject: [GHC] #8686: "cannot find normal object file" error during compilation Message-ID: <048.daebe0f34dcf7ef994936ff981966697@haskell.org> #8686: "cannot find normal object file" error during compilation -----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- When I try to compile tests provided in the [http://hackage.haskell.org/package/singletons singletons] package I get the following error: {{{ Building singletons-0.9.3... Preprocessing library singletons-0.9.3... In-place registering singletons-0.9.3... Preprocessing test suite 'compile' for singletons-0.9.3... [ 6 of 20] Compiling Data.Singletons.Core ( Data/Singletons/Core.hs, dist/build/compile/compile-tmp/Data/Singletons/Core.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.3.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package syb-0.4.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package th-desugar-1.2.1 ... linking ... done. Loading package newtype-0.2 ... linking ... done. Loading package constraints-0.3.4.2 ... linking ... done. Data/Singletons/Core.hs:1:1: cannot find normal object file ?dist/build/compile/compile- tmp/Data/Singletons/Util.dyn_o? while linking an interpreted expression }}} This happens on HEAD but not on 7.6.3. Steps to reproduce: 1. Download and extract singletons source code 2. In the cabal file uncomment test-suite section (which is commented out because it doesn't work) 3. `cabal configure --enable-tests && cabal build` Reproducing this requires installing packages required by singletons. I'm setting milestone to 7.8 as this is something that looks like a blocker in a stable release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 15:09:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 15:09:13 -0000 Subject: [GHC] #8686: "cannot find normal object file" error during compilation In-Reply-To: <048.daebe0f34dcf7ef994936ff981966697@haskell.org> References: <048.daebe0f34dcf7ef994936ff981966697@haskell.org> Message-ID: <063.211d15daf779cbdd39648d295eaabbbb@haskell.org> #8686: "cannot find normal object file" error during compilation ---------------------------------------+----------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by jstolarek): Oh wait, I'm being told that 7df27d52cffa915886b9f2860e961a0e7bb5dd1 might have fixed that. I'll check and report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 15:41:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 15:41:21 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.9d507f1ee53c7a1375803a4d9bd0621d@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by simonmar): Replying to [comment:40 awson]: > If we leave {{{lookupSymbol}}} unmodified then address of "far" symbol, imported from DLL, and returned by {{{lookupSymbol}}} is different from trampoline address. Is this ok? Or do I completely misunderstand the picture? That should be fine. Callers of `lookupSymbol` probably want the real address, not a newly allocated trampoline. If we allocated a trampoline for every call to `lookupSymbol`, we would have a problematic memory leak. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 15:41:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 15:41:42 -0000 Subject: [GHC] #7596: Opportunity to improve CSE In-Reply-To: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> References: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> Message-ID: <061.d87a00b44b3e8fdab12e2b20b0392478@haskell.org> #7596: Opportunity to improve CSE -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): As suggested, I made CSE much more aggressive by floating out much more expressions, so that `Just x` is CSE?ed in {{{#!haskell module T7596 where f :: Maybe Int -> (Bool, Bool) f Nothing = (True, True) f _ = (False, True) {-# NOINLINE f #-} g :: Maybe Int -> (Bool, Bool) g Nothing = (True, True) g _ = (False, True) {-# NOINLINE g #-} foo :: Int -> Bool foo x = case f (Just x) of (a, b) -> case g (Just x) of (p,q) -> a && b && p && q }}} It hardy helps, though: {{{ Min -0.6% -14.1% -33.0% -33.9% -20.0% Max +0.6% +178.2% +85.2% +86.1% +50.0% Geometric Mean -0.2% +14.1% +13.1% +12.5% +0.8% }}} But that is no surprise; it CSE?s dictionary access functions like `lvl1 = GHC.Classes.<= @ a sc` ? not much to win here. Preventing aggresive floating of partial applications... slightly better, but still horrible: {{{ Min -0.7% -14.1% -53.0% -55.4% -20.0% Max +0.5% +178.2% +25.9% +25.9% +50.0% Geometric Mean -0.4% +13.6% -16.8% -18.1% +0.6% }}} For example `spectral/sorting`: `+123.1%` increase, due to the expression `reverse rev` shared in this code {{{#!haskell insertSort [] = [] insertSort (x:xs) = trins [] [x] xs where trins :: Ord a => [a] -> [a] -> [a] -> [a] trins rev [] (y:ys) = trins [] ((reverse rev) ++ [y]) ys trins rev xs [] = (reverse rev) ++ xs trins rev (x:xs) (y:ys) | x < y = trins (x:rev) xs (y:ys) | True = trins [] (reverse rev ++ (y:x:xs)) ys }}} Clearly CSE?ing something from different branches can never be a win (besides potentially code size). But that is something the current CSE code cannot check, right? And even in the example from the ticket description, it is not stupid not to do CSE: With some luck the first `I#` allocated will be free before the next GC run, causing no copying. After CSE it stays alive for longer, causing more work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 18:17:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 18:17:19 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.80eb3a58083196372cc32479073edaa5@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): Unfortunately, things are still broken with BFD ld due to ld bug 16177 (https://sourceware.org/bugzilla/show_bug.cgi?id=16177) wherein ld inexplicably generates R_ARM_COPY relocations where a standard R_ARM_ABS32 relocation would do just fine (as gold does). Sadly, despite the bug being reported two months ago, there has been no activity from the ld side. For now I suspect we'll just have to advise users to use gold on ARM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 18:36:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 18:36:02 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.21ce287d3d7f1c744844244b60b5892a@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): Actually, this is quite perplexing as I would have expected the R_ARM_COPY relocation to have already been performed by ld.so by the time we get to executing code. That being said, in place of numerous data symbols I see what appears to be trampoline code, {{{ #5 0xb61f8eaa in evacuate (p=0xb5cfd194) at rts/sm/Evac.c:384 384 ASSERTM(LOOKS_LIKE_CLOSURE_PTR(q), "invalid closure, info=%p", q->header.info); (gdb) print q $1 = (StgClosure *) 0x16bf8 (gdb) print *q $2 = {header = {info = 0x16d64 }, payload = 0x16bfc } (gdb) x /5i 0x16d64 0x16d64 : ldr r3, [r5] 0x16d68 : add r7, r7, #1 0x16d6c : blx r3 0x16d70 : bx lr 0x16d74: movs r0, r0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 19:18:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 19:18:16 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.e9b65cfc554a4b8129b1deafbeb091c2@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Tim Schroeder writes (on Haskell Cafe) Hello, I have developed various profiling and debugging tools in the past, but haven't done any work in that direction for GHC compiled Haskell programs. I thought a good start might be to write a document detailing how the call stack works in GHC, and also write a basic debugger stack trace tool. Here: [https://github.com/blitzcode/ghc-stack] I hope this is helpful to people trying to pin down crashes, and people interested in working on debugging / profiling tools. I'd also really appreciate if somebody with more GHC / RTS knowledge than me would have a look and see if I got things right. Cheers, Tim -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 19:36:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 19:36:02 -0000 Subject: [GHC] #8686: "cannot find normal object file" error during compilation In-Reply-To: <048.daebe0f34dcf7ef994936ff981966697@haskell.org> References: <048.daebe0f34dcf7ef994936ff981966697@haskell.org> Message-ID: <063.61cb15475b55933fb473a1a4424c73bb@haskell.org> #8686: "cannot find normal object file" error during compilation ---------------------------------------+----------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => worksforme Comment: Yeah, the problem is gone with latest HEAD. I'm closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 19:47:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 19:47:51 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.54dd491695cbab56db144229fe7666ff@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): It turns out that the code above is the same as is seen in `libHSghc- prim*.so` so it seems that the `R_ARM_COPY` relocation is indeed being correctly performed. Given that this same code works with gold, it seems likely that this isn't trampoline code but instead the correct code for this symbol. I now think that it is the copy itself that is causing the crash due to tables-before-code. While the linker knows to copy the symbol itself, it doesn't copy the info table preceding it. Trying to make the runtime linker do the right thing with `R_ARM_COPY` with tables-before-code enabled is going to be very difficult, if not impossible. If this hypothesis is correct, we should disable tables- before-code on ARM when using affected linkers (all versions of bfd ld, as far as I can tell). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 20:21:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 20:21:59 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.d9955a5c0e27d377f75cf3e521026a3e@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Yes, `R_COPY` relocations and tables-next-to-code don't work well together, so I believe we do some trickery on other platforms to avoid the linker from generating them. take a look at `compiler/nativeGen/PIC.hs` and search for "copy". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 20:28:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 20:28:01 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.cf43240b7d5d113872039688a6b10442@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by hvr): * related: => #8439 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 20:28:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 20:28:28 -0000 Subject: [GHC] #8439: add a CPP program field to Settings file (decouple CPP program and C compiler choice) In-Reply-To: <045.b102c8aef525c2e2e4e30540ff75513b@haskell.org> References: <045.b102c8aef525c2e2e4e30540ff75513b@haskell.org> Message-ID: <060.9eb84840233dfb5b716170fea05a1cf1@haskell.org> #8439: add a CPP program field to Settings file (decouple CPP program and C compiler choice) -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8683 -------------------------------------+------------------------------------ Changes (by hvr): * related: => #8683 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 20:47:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 20:47:39 -0000 Subject: [GHC] #8687: Strange closure type 9983 Message-ID: <042.e67240730f3538eb274d4089a3c1c88e@haskell.org> #8687: Strange closure type 9983 ------------------------------------+------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- {{{ *Main> :main C:\\Windows\\Media\\onestop.mid : internal error: evacuate: strange closure type 9983 (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} This happened to me on {{{ghci playmidi.hs}}} from the {{{examples/}}} folder of {{{http://hackage.haskell.org/package/hmidi-0.2.1.0}}} (downloaded the tar and fixed the parsec import, removing the {{{"parsec2"}}} package import and fixing a type checking error, replacing {{{selectOutputDevice Nothing}}} by {{{selectOutputDevice "Select midi output device" Nothing}}}. (We also fixed those compile errors at https://github.com/vahokif/hmidi/tree/2124a8.) I have not been able to reproduce it since the first time :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 21:51:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 21:51:34 -0000 Subject: [GHC] #6089: Allow declaration splices inside declaration brackets In-Reply-To: <044.85bbefd435d2792cc792b502a5ebe47e@haskell.org> References: <044.85bbefd435d2792cc792b502a5ebe47e@haskell.org> Message-ID: <059.85045d209d5f2c98d7e3f4784faefd94@haskell.org> #6089: Allow declaration splices inside declaration brackets ----------------------------------------------+---------------------------- Reporter: igloo | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by monoidal): With {{{ decs :: Q [Dec] decs = [d|$( [d| fun3 = undefined |] ) |] }}} GHC 7.6 complains, but GHC 7.7 apparently ignores the splice - `$decs` does not bring `fun3` into scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 21:54:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 21:54:04 -0000 Subject: [GHC] #8688: internal error: stg_ap_p_ret Message-ID: <048.a449a45e89bcdd1d34e6aa01b703899b@haskell.org> #8688: internal error: stg_ap_p_ret ------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When in GHCi I get: : internal error: stg_ap_p_ret (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug There is probably something wrong with the FFI binding I am testing; under other circumstances I get a segfault. But since I was asked to report this, here I am. Let me know if I can provide anything else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 22:06:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 22:06:15 -0000 Subject: [GHC] #8688: internal error: stg_ap_p_ret In-Reply-To: <048.a449a45e89bcdd1d34e6aa01b703899b@haskell.org> References: <048.a449a45e89bcdd1d34e6aa01b703899b@haskell.org> Message-ID: <063.39307f70dabb7f31694ffba4785e1f15@haskell.org> #8688: internal error: stg_ap_p_ret -------------------------------------+------------------------------------ Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): Could you give a way to reproduce it - ideally a runnable file? Or, try your code with GHC HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 20 22:39:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Jan 2014 22:39:19 -0000 Subject: [GHC] #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction In-Reply-To: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> References: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> Message-ID: <063.64afd38d9d913b9050b3f2782964c17a@haskell.org> #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction --------------------------------------------+------------------------------ Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 ezyang): I haven't checked your program, but what you have textually described is the behavior I would expect for orElse (and is consistent with the semantics): the 'else' branch is only valid if the 'if' branch retries; so if the first branch is invalidated, it may not be retrying anymore. This suggests there might be a useful nondeterministic version of orElse, which relaxes this restriction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 05:34:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 05:34:21 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.8381cc17b33ff559d764f6ee79cdd0ee@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): Replying to [comment:15 carter]: > could you walk me through why > {{{ > {-# SPECIALIZE plusFastCyc :: (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) -> (FastCyc (VT U.Vector m) Int) #-} > }}} > isn't satisfactory? I added some more code to demonstrate something more like a real use case for the program: http://lpaste.net/98840. It has the same issue as `Foo.hs` above, but hopefully you can see why the constraint is needed. I wanted to remove it from the example to show that the problem wasn't type families, constraint kinds, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 05:38:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 05:38:21 -0000 Subject: [GHC] #8689: confusing comment in compiler/main/SysTools.lhs Message-ID: <045.cb716bf4926e5132d3b596b76f597be0@haskell.org> #8689: confusing comment in compiler/main/SysTools.lhs ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- on line 341 {{{ -- Hans: this isn't right in general, but you can -- elaborate it in the same way as the others }}} I have NO idea what that comment is referring to -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 05:49:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 05:49:27 -0000 Subject: [GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining In-Reply-To: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> References: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> Message-ID: <063.a6dfcd44364d8f40112323f7d5c2f36d@haskell.org> #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining -------------------------------------+------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 05:49:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 05:49:48 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.99e3980e1d7763d726587d5452affcfb@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): Ok, i've started digging into this, with the idea of having the settings file have the "Haskell CPP Command" and "Haskell CPP Flags" fields. the idea being that the settings file would determine the CPP and flags unless pgmp and optp are set. soo, some of the CPP stuff is welded into certain config and other steps currently eg in mk/config.mk.in {{{ # It's not easy to separate the CPP program from its flags, as # AC_PROG_CPP defines CPP as "/usr/bin/gcc -E" CPP = @CPP@ @CPPFLAGS@ # # RAWCPP_FLAGS are the flags to give to cpp (viz, gcc -E) to persuade it to # behave plausibly on Haskell sources. # # Clang in particular is a bit more annoying, so we suppress some warnings. RAWCPP_FLAGS = -undef -traditional ifeq "$(CC_CLANG_BACKEND)" "1" RAWCPP_FLAGS += -Wno-invalid-pp-token -Wno-unicode -Wno- trigraphs endif }}} which then in compiler/ghc.mk as part of the Config module has the line {{{ @echo 'cRAWCPP_FLAGS :: String' >> $@ @echo 'cRAWCPP_FLAGS = "$(RAWCPP_FLAGS)"' >> $@ }}} and then in compiler/main/SysTools.lhs we have {{{ let cpp_prog = gcc_prog cpp_args = Option "-E" : map Option (words cRAWCPP_FLAGS) ++ gcc_args }}} Interestingly, the -pgmP flag corresponds to {{{ sPgm_P = (cpp_prog, cpp_args), }}} and the optP flag is by default empty! {{{ sOpt_P = [] }}} so optP is meant for adding *additional* flags to cpp, but shouldn't be part of the default config, AND pgmP should be used to specify the full "cpp program and the prefix of args?" also currently it looks like cpp_args also passes in applicable gcc_args. (are there some examples of when thats used?!) theres probably some other things i'm overlooking, but thats the obvious stuff. I think I now understand enough to be able to cook up a strawman patch for this stuff, including the config time settings.in stuff, the piece that currently goes into the magic Config.hs hack that now should move into settings, and some of the dynflags / settings stuff. I'll try to hack it out tomorrow late afternoon. (though if someone beats me to it, they're welcome, i've never messed with autoconf before, though I think i can cargo cult write the correct changes there,) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 09:16:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 09:16:03 -0000 Subject: [GHC] #8031: Template Haskell gets confused with kind variables introduced in separate foralls In-Reply-To: <047.defe71e5e3f09763c5eefe74f7326e80@haskell.org> References: <047.defe71e5e3f09763c5eefe74f7326e80@haskell.org> Message-ID: <062.58b3ffb6189c58b4b9ea134262128061@haskell.org> #8031: Template Haskell gets confused with kind variables introduced in separate foralls -----------------------------+--------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: TemplateHaskell PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -----------------------------+--------------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 09:19:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 09:19:47 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.b47c69aa62fc31cc1ca28c4dcc8f13d8@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): I've created a new patch. It is made against 7.6.3 and I think the port to HEAD should be straightforward. 1. I reuse {{{oc->symbol_extras}}}; 2. Memory for trampolines is allocated in the single shot; 3. This memory can handily be freed in {{{freeObjectCode}}} (in HEAD, we have no {{{freeObjectCode}}} in 7.6.3); 4. Fixed bug when trampolined symbols were not added to symbol hash table. If the patch is accepted I'll port it to HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 09:31:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 09:31:07 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.44b879951021abee7f539570ef675e6c@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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 Tarrasch): Wow, this is amazing! There's also a discussion tree at reddit: http://www.reddit.com/r/haskell/comments/1vo1se/hacking_ghcs_stack_for_fun_and_profit_featuring/ Tim covers a lot of interesting stuff I have not really had time nor knowledge to dive into. In particular he confronts the difficulties of foreign function calls and receiving signals that don't get turned into Haskell exceptions, like `unsafeWrite v 1000000000 (0 :: Int)` in contrast to `error "rts-aware exception"`. For my thesis work, I'll be sticking with how to handle RTS-aware exceptions. But I'll be enthusiastically following how Tim's ghd is progressing. His README on the github page is a very, very well-written and good read. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 09:32:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 09:32:13 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.1d243887af2e4df4aba36260e1fb9222@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by awson): https://ghc.haskell.org/trac/ghc/attachment/ticket/7134/ghc-7.6.3-w64fix2.patch is now relevant, so I change this one too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 15:25:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 15:25:27 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.91d44075b30a6f566c206de44fc7f506@haskell.org> #8657: -fregs-graph still has a limit on spill slots ---------------------------------------+----------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7679 ---------------------------------------+----------------------------------- Changes (by simonmar): * priority: highest => normal * milestone: 7.8.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 15:28:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 15:28:59 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.579a485c0e275c4f810a47d0fd8b9df6@haskell.org> #5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: This is now merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 15:29:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 15:29:32 -0000 Subject: [GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault In-Reply-To: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> References: <046.a1de52e736c53bf94deece978e2702d5@haskell.org> Message-ID: <061.aa7b205b947600851e8cfe0dac308cf5@haskell.org> #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: 7.8.1 => 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 15:29:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 15:29:44 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.50f101c1a5d1efbc9b66827c479dbabd@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files --------------------------------------------+------------------------------ Reporter: ezyang | Owner: Type: bug | thoughtpolice Priority: highest | Status: new Component: Compiler | Milestone: 7.8.2 Resolution: | Version: 7.7 Operating System: Windows | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: cabal01 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #7134 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * milestone: 7.8.1 => 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 15:30:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 15:30:04 -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.af3ee9eb598dc422b31bdd3453d1287a@haskell.org> #5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.10.1 => 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 15:34:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 15:34:01 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238677=3A_Perhaps_you_haven=27t_insta?= =?utf-8?q?lled_the_=22p=5Fdyn=22_libraries_for_package_=E2=80=9B?= =?utf-8?q?integer-gmp=E2=80=99?= In-Reply-To: <044.6132243068a2d94d675acf18884e3da4@haskell.org> References: <044.6132243068a2d94d675acf18884e3da4@haskell.org> Message-ID: <059.b503afa45f0e7dfe2e9fe85f67697852@haskell.org> #8677: Perhaps you haven't installed the "p_dyn" libraries for package ?integer- gmp? -------------------------------------+---------------------------------- Reporter: erikd | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 15:43:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 15:43:15 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.9b8dbd75c3b743510b62b14382b5801a@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by simonmar): One thing worries me about this patch: isn't it possible that `VirutalAlloc` will give you some memory that is more than a 32-bit offset away from the source of the jump, which would mean that your trampoline would be too far away? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 16:42:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 16:42:25 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.69f9f71a2cbb053bd58c6cf9e50ac030@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): In theory, it's possible. There is even a comment in my code exactly about this. I'll cite it here: "Unlike in unixish case we don't bother to guarantee extras are laid out next to object image in memory. It looks Windows allocator don't suddenly want to allocate memory from top to down if we don't tell him so. And we don't." {{{VirtualAlloc}}} has a special flag {{{MEM_TOP_DOWN}}} which according to http://msdn.microsoft.com/en- us/library/windows/desktop/aa366887%28v=vs.85%29.aspx: "Allocates memory at the highest possible address". Without this flag it (as I tested) allocates memory "not far away from here". I agree this is not a strong guarantee, but, as of now, all works perfectly. Also, {{{VirtualAlloc}}}'ed ({{{oc->image}}} is allocated with {{{VirtualAlloc}}}) memory can't be reallocated without explicit new allocation and data copying. Sure, it won't take much to implement all this, but I just can't bring myself to do it right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 17:36:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 17:36:30 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.4cda32ee8a366d541d6fee468a369186@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > The demand analyser currently analyses the function before the body. One could do a second round, but there is a risk of exponential blow-up. In this case, the let is a recursive let anyways, so we are going to do multiple iterations. Do we really need to avoid re-analysis so hard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 19:30:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 19:30:57 -0000 Subject: [GHC] #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction In-Reply-To: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> References: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> Message-ID: <063.c656ad1d09b1647e34a1379054cd2281@haskell.org> #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction --------------------------------------------+------------------------------ Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 jberryman): Replying to [comment:2 ezyang]: > I haven't checked your program, but what you have textually described is the behavior I would expect for orElse (and is consistent with the semantics): the 'else' branch is only valid if the 'if' branch retries; so if the first branch is invalidated, it may not be retrying anymore. So I think I got caught up in the details and convinced myself that there wasn't really a way to do any useful reasoning with this behavior. But I suppose it lets you say e.g. "if we're in the right branch then our view of the world is one where predicate P from the left branch is False", even if the two branches share no variables and the first is rolled back. > This suggests there might be a useful nondeterministic version of orElse, which relaxes this restriction. Now I'm not even sure that the current `orElse` behavior won't work for me. Would it be better to update this ticket when I have a clearer idea, or just consider opening a new feature request ticket in the future? Thanks for the feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 20:07:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 20:07:07 -0000 Subject: [GHC] #8180: Template Haskell now requires -dynamic or -dynamic-too In-Reply-To: <047.1c653d82d918be711217186a104a0ee9@haskell.org> References: <047.1c653d82d918be711217186a104a0ee9@haskell.org> Message-ID: <062.8b2c376407a0292e66725c71cd9a8807@haskell.org> #8180: Template Haskell now requires -dynamic or -dynamic-too -------------------------------------+------------------------------------ Reporter: goldfire | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"0a2d323cee040c6460233ff17d40199755e59959/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0a2d323cee040c6460233ff17d40199755e59959" Fix #8677 (fallout from #8180) When using TemplateHaskell and -prof, we *do not* want -dynamic-too, because we're going to *expect* that you compiled the vanilla/dyn way already, and are compiling profiling the second time (i.e. so GHCi can just load the normal, non-profiled object files.) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 20:07:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 20:07:07 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238677=3A_Perhaps_you_haven=27t_insta?= =?utf-8?q?lled_the_=22p=5Fdyn=22_libraries_for_package_=E2=80=9B?= =?utf-8?q?integer-gmp=E2=80=99?= In-Reply-To: <044.6132243068a2d94d675acf18884e3da4@haskell.org> References: <044.6132243068a2d94d675acf18884e3da4@haskell.org> Message-ID: <059.a2be47a761d489af7917c796cde2d448@haskell.org> #8677: Perhaps you haven't installed the "p_dyn" libraries for package ?integer- gmp? -------------------------------------+---------------------------------- Reporter: erikd | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"0a2d323cee040c6460233ff17d40199755e59959/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0a2d323cee040c6460233ff17d40199755e59959" Fix #8677 (fallout from #8180) When using TemplateHaskell and -prof, we *do not* want -dynamic-too, because we're going to *expect* that you compiled the vanilla/dyn way already, and are compiling profiling the second time (i.e. so GHCi can just load the normal, non-profiled object files.) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 21 20:08:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Jan 2014 20:08:45 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238677=3A_Perhaps_you_haven=27t_insta?= =?utf-8?q?lled_the_=22p=5Fdyn=22_libraries_for_package_=E2=80=9B?= =?utf-8?q?integer-gmp=E2=80=99?= In-Reply-To: <044.6132243068a2d94d675acf18884e3da4@haskell.org> References: <044.6132243068a2d94d675acf18884e3da4@haskell.org> Message-ID: <059.de88dbcb54eb260fe14a94a42769cc2a@haskell.org> #8677: Perhaps you haven't installed the "p_dyn" libraries for package ?integer- gmp? -------------------------------------+---------------------------------- Reporter: erikd | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: This should now be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 02:52:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 02:52:37 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.1e839ad9fb24e986f7968a09dcfb0992@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): heres my current notes, which sort of restate my prior comment NOTES from config.mk.in {{{ CONTEXT_DIFF = @ContextDiffCmd@ CP = cp # It's not easy to separate the CPP program from its flags, as # AC_PROG_CPP defines CPP as "/usr/bin/gcc -E" CPP = @CPP@ @CPPFLAGS@ # # RAWCPP_FLAGS are the flags to give to cpp (viz, gcc -E) to persuade it to # behave plausibly on Haskell sources. # # Clang in particular is a bit more annoying, so we suppress some warnings. RAWCPP_FLAGS = -undef -traditional ifeq "$(CC_CLANG_BACKEND)" "1" RAWCPP_FLAGS += -Wno-invalid-pp-token -Wno-unicode -Wno- trigraphs endif }}} RAWCPP is then used in compiler/ghc.mk to define {{{ @echo 'cRAWCPP_FLAGS :: String' >> $@ @echo 'cRAWCPP_FLAGS = "$(RAWCPP_FLAGS)"' >> $@ }}} which is then used in compiler/main/SysTools.lhs to do {{{ 234 gcc_prog <- getSetting "C compiler command" 235: gcc_args_str <- getSetting "C compiler flags" .... let cpp_prog = gcc_prog 289 cpp_args = Option "-E" 290 : map Option (words cRAWCPP_FLAGS) 291: ++ gcc_args }}} and then intiizes (still in SysTools) {{{ sPgm_P = (cpp_prog, cpp_args), }}} then in compiler/main/DynFlags.hs {{{ 1807: setPgmP f = let (pgm:args) = words f in alterSettings (\s -> s { sPgm_P = (pgm, map Option args)}) }}} and then still in compiler/main/DynFlags.hs {{{ 2144: , Flag "pgmP" (hasArg setPgmP) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 07:21:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 07:21:36 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.95f192c0f635f7146d398904d3510b32@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): ok, I htink i now understand enough of the autoconf to post a link to a strawman patch shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 08:19:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 08:19:26 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.655164c94d350f0c1e928bef8b543ddb@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): heres a WIP patch, haven't tested it yet, and theres probably stuff i'm overlooking. (also I don't know m4 /autoconf :) ) https://github.com/cartazio/ghc/compare/cpp_settings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 09:05:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 09:05:35 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.3b9d8de86e9193283f7e9827d7509734@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): I've made preliminary port of this patch to HEAD. It works on my Windows 8 64-bit boxes, but some mentions should be made: 1. I've disabled {{{.ctor}}} section handling. It was introduced recently and does not work on x86_64 mingw32 barfing {{{can't find section `'}}}; 2. It turned out STG allocator (which uses standard C {{{malloc}}}, which, in turn, uses {{{HeapAlloc}}} on Windows) can allocate some memory from high addresses. This did not occured when I allocated trampolines area with {{{VirtualAlloc}}} directly, but it makes Symon's concerns looks much more reasonable than I thought before. Probably, it is worth efforts to guarantee placement of trampolines area next to object image in memory as it is made in unixish code. Especially because we now allocate trampolines for all externs and not only for undefined externs (which accidentally was enough for 7.6.3) precisely because of STG allocator puts some *defined* externs to high addresses. Anyway, right now this patch makes x86_64 mingw32 working! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 09:10:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 09:10:17 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.408d39bcc43b60f095fe599d6f7296f6@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by awson): Previous patches were buggy and worked on 7.6.3 by accident. This new patch is more or less independent and works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 13:47:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 13:47:26 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.335880f9e3463a8c2705ba2e1735d671@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I gave it a shot, analysing the body and the rhs of a let in alternation until a fixed point is found with regard to * demand on the rhs * rhs?s demand type * body?s demand type and as expected, the resulting core looks good: {{{ $wgo_s1oi [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.Double# -> GHC.Prim.Double# -> Data.Complex.Complex GHC.Types.Double [LclId, Arity=3, Str=DmdType ] $wgo_s1oi = \ (w_s1o3 :: GHC.Prim.Int#) (ww1_s1oa :: GHC.Prim.Double#) (ww2_s1of :: GHC.Prim.Double#) -> case Foo.f (GHC.Types.I# w_s1o3) of _ [Occ=Dead] { Data.Complex.:+ ww4_s1nS ww5_s1nX -> case ww4_s1nS of _ [Occ=Dead] { GHC.Types.D# ww7_s1re -> case ww5_s1nX of _ [Occ=Dead] { GHC.Types.D# ww9_s1rg -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.==# w_s1o3 ww_s1om) of _ [Occ=Dead] { GHC.Types.False -> $wgo_s1oi (GHC.Prim.+# w_s1o3 1) (GHC.Prim.+## ww1_s1oa ww7_s1re) (GHC.Prim.+## ww2_s1of ww9_s1rg); GHC.Types.True -> Data.Complex.:+ @ GHC.Types.Double (GHC.Types.D# (GHC.Prim.+## ww1_s1oa ww7_s1re)) (GHC.Types.D# (GHC.Prim.+## ww2_s1of ww9_s1rg)) } } } }; } in $wgo_s1oi 1 0.0 0.0; }}} But also as expected, for other code, with more nested lets, compilation time becomes unacceptably large. Has anyone considered doing the fixed-pointing not locally for every let, but across the whole top-level-binding? I.e. initialize all demands and strictness signatures with their strongest possible value (`absDmd` and `botDmdType`), and then analyse the whole expression in repeated passes over all of it, until nothing changes any more. (Or, a variant: Do that initialisation, but also do local fixed-pointing, starting from the stored values, so that when an inner let is re-analysed, but nothing has changed, then there is only one iteration.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 16:25:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 16:25:02 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.ea3de5bb08c1ef58e2e622973f648e44@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): The patch nearly works, I'm having trouble getting m4/autconf to work quite right, could someone who's more familiar with it chime in? I *think* once the stuff involving {{{ "$WhatIsHaskellCPPCalled"}}} and {{{ "$WhatAreCPPFlags" }}} is fixed. I'm somehow not using the autconf quite correctly to properly instantiate the CPP cmd and CPP Flags fields of settings correctly. Some help would be appreciated! i've also done a test build where i by hand set {{{ ("Haskell CPP command","/Users/carter/bin/gcc"), ("Haskell CPP flags","-E -undef -traditional" ), }}} in my "settings" file after the configure step ran to validate the rest of the build process, and that works (ie testing that if i set it by hand, the new /DynFlags.hs etc logic behaves correctly). Namely that I manage to get stage2 to build correctly sooo, I think all thats left is figuring out what i'm doing wrong on the m4/ autoconf front -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 16:25:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 16:25:31 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.995468e14dcc748248f43b381e8a0e4b@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): the patch can be found via https://github.com/cartazio/ghc/compare/cpp_settings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 16:26:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 16:26:41 -0000 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> References: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> Message-ID: <061.baf51e69827da123123c65115cb0787d@haskell.org> #915: Implement list fusion using streams instead of foldr/build ----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: | Version: 6.8 libraries/base | Keywords: fusion Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more than a week) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by duncan): We do now have a solution, however the current implementation relies on HERMIT. See: ''The HERMIT in the Stream -- Fusing Stream Fusion?s concatMap'' by Andrew Farmer, Christian H?ner zu Sierdissen and Andy Gill. http://ittc.ku.edu/~afarmer/concatmap-pepm14.pdf See also this summary/commentary: http://blog.ezyang.com/2014/01/pepm14 -the-hermit-in-the-stream/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 17:12:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 17:12:49 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.f8472e0cb66c7bc0300eaee54d61c3ec@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): > (Or, a variant: Do that initialisation, but also do local fixed- pointing, starting from the stored values, so that when an inner let is re-analysed, but nothing has changed, then there is only one iteration.) Ah, so that is what `ae_virigin` is all about... doing the same trick in my code helps in keeping compilation times down; but I must be introducing bugs somewhere; compiled with my code GHC itself goes into infinite loops ? but that is a problem for another day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 18:09:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 18:09:53 -0000 Subject: [GHC] #8690: Failed to compile Win32 libraries using 64 bit GHC. Message-ID: <055.b6678f8a776bfc0e56a242b0c9070f8a@haskell.org> #8690: Failed to compile Win32 libraries using 64 bit GHC. -----------------------------------+--------------------------------------- Reporter: | Owner: andrewrademacher | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Windows Keywords: | Type of failure: Compile-time crash Architecture: x86_64 (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Loading package Win32-2.3.0.0 ... linking ... ghc.exe: internal error: R_X86_64_PC32: High bits are set in 7ffb728ca4d4 for DefDlgProcW (GHC version 7.6.3 for x86_64_unknown_mingw32) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 19:33:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 19:33:03 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.7b20777d79d50002eca951448b9f6752@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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 blitzcode): Thank you for your kind words! I've been most interested in the lower-level faults simply because they have the least support from the existing tools. I'm currently back on another project after spending a week or so on the debugging project, but I'm thinking about how to turn it into a a more usable and portable tool. Basically, I think I would rewrite it to be based fully on gdb's machine interface or lldb's C++ API. This buys me a few things: - Unified code to access the target process state (no more Win32 ReadProcessMemory() vs Linux ptrace() vs OS X mach_vm_read_overwrite()) - Unified code for symbol lookup (no more Win32 Sym* APIs vs Linux addr2line vs OS X / BSD atos) - Support for both stack traces from live processes and core dumps with no extra work - C/C++/etc. stack unwinding already done The biggest issue still seems to be keeping the debugger's view of the stack and heap in sync with the runtime / compiler sources. GHC's RTS data structures / memory layout seem fairly stable from what I can tell, but I'd like to make everything as automatic as possible. After all, there are quite a few different OS, CPU architecture, compiler and RTS flavors to support. I would use the DerivedConstants.h header and generate some additional offsets, register mappings and such using a similar mechanism. I still think the approach of directly accessing the target process through OS-level functions has some merit. Mostly for profiling, where we'd like to inspect the program hundreds or even thousands of times per second with as little overhead as possible. The CCS is a fairly good tool for pinning down the location of a crash, but Peter's work on improving DWARF information is really what I'm looking forward to for profiling. Hopefully this can be a part of 7.10! Peter, do your DWARF improvements handle FFI calls (traversing from C back into Haskell)? Also, do you think it would be feasible to support frame pointers as an option for GHC? I know debuggers have long moved on to doing stack unwinding with debug information, but there seem to be numerous profiling tools still using them for speed and simplicity. There's been some discussion here regarding RTS APIs to access the stack, but are there any ideas on how to expose this API to other processes? There are advantages to having debugging, profiling and heap walking tools be as unobtrusive as possible, not changing the program code or runtime behavior. RTS support for this type of access could make writing such tools simpler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 20:34:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 20:34:57 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.f5b2e583ef01c6ab7492b10f0eb307a0@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by trommler): Replying to [comment:7 carter]: > the patch can be found via https://github.com/cartazio/ghc/compare/cpp_settings I sent a pull request to your github repository. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 21:34:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 21:34:06 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.0c920a5cf911bb673d9c8b7db1f2fed2@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): thanks Peter! (merged it in) that solves one set of problems, next we need to understand why 1) when i set --with-gcc=clang, the clang variant of the CPP flags isn't chosen 2) while the cpp: foo, cpp-flags : blah info is printed in the configure script summary, it isn't substituted into the settings file! the CPP field is empty, and the CPP-Flags field @variableName@ isn't even substituted away. I suspect I'm not understanding how to use AC_SUBST([blah]) correctly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 21:45:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 21:45:03 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.8f8f59e94ed317b63b0040c8c7960abe@haskell.org> #5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by monoidal): Reminder: we still need documentation and release notes entry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 23:10:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 23:10:23 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.489167db88bb22e584b7bcf5f3e0a9e0@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Changes (by carter): * status: new => patch Comment: ok, the configure setup pieces now work! (thanks peter!) one last thing that peter has suggested, and I agree with, is that we should add that using --with-cpp=foo then requires you to specify a --with-cpp-flags=blah (because theres no general way to determine the right flags, so they must be user supplied if you're specifying your own cpp) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 23:11:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 23:11:29 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.8ab2a3eeeb9212ef89ee424713b9ade1@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): So i think this patch *works* now. Feedback appreciated / welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 23:45:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 23:45:43 -0000 Subject: [GHC] #8691: Investigate recent 32bit compiler performance regressions Message-ID: <052.41eb9b4e222365a4301468f44cacdd14@haskell.org> #8691: Investigate recent 32bit compiler performance regressions -------------------------+------------------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.8.1 Priority: | Version: 7.7 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- In c5088e299a66109346057afc151c33e47b850b92 I tweaked the numbers for the x86/Linux build to get them to pass for the RC, but some of these look pretty bad. Most of them shot up quite a bit. Some of them I don't think were very recent (modification date unspecified, etc.) A few others had updates as early as November, so something has clearly slipped on 32bit platforms here. I spent a tiny amount of time investigating, but didn't get very far. I'm not holding the RC for these, but it's worth investigating when we get a chance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 22 23:45:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Jan 2014 23:45:54 -0000 Subject: [GHC] #8691: Investigate recent 32bit compiler performance regressions In-Reply-To: <052.41eb9b4e222365a4301468f44cacdd14@haskell.org> References: <052.41eb9b4e222365a4301468f44cacdd14@haskell.org> Message-ID: <067.cfd8dc4825d4b692ef23a9df8aeaec49@haskell.org> #8691: Investigate recent 32bit compiler performance regressions -------------------------------------------------+------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 00:01:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 00:01:20 -0000 Subject: [GHC] #8691: Investigate recent 32bit compiler performance regressions In-Reply-To: <052.41eb9b4e222365a4301468f44cacdd14@haskell.org> References: <052.41eb9b4e222365a4301468f44cacdd14@haskell.org> Message-ID: <067.8daf463b7b14dc946dd80b2f5963bf0a@haskell.org> #8691: Investigate recent 32bit compiler performance regressions -------------------------------------------------+------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by thoughtpolice): I'm double checking this because I may have accidentally made an error in my build settings. Will report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 01:25:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 01:25:19 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.74f14695755d4f86e238d0d42a99ba8f@haskell.org> #5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by cactus): What documentation is needed beside the new section in `docs/users_guide/glasgow_exts`? Also, can you point me in the direction of the release notes? I'd like to add a note not just mentioning pattern synonyms but also explaining that it is a preview that will need feedback from actual usage and which has more features planned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 04:27:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 04:27:47 -0000 Subject: [GHC] #8691: Investigate recent 32bit compiler performance regressions In-Reply-To: <052.41eb9b4e222365a4301468f44cacdd14@haskell.org> References: <052.41eb9b4e222365a4301468f44cacdd14@haskell.org> Message-ID: <067.636c25d6c4aecc7b68a792469d5edd9e@haskell.org> #8691: Investigate recent 32bit compiler performance regressions -------------------------------------------------+------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: Priority: high | closed Component: Compiler | Milestone: 7.8.1 Resolution: invalid | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => invalid Comment: This turned out to be bogus, my bad! Most of the numbers look OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 08:57:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 08:57:28 -0000 Subject: [GHC] #8029: batch-mode recompilation checking sometimes fails In-Reply-To: <045.fbb1c0736cf81083c94a9ff0372ae621@haskell.org> References: <045.fbb1c0736cf81083c94a9ff0372ae621@haskell.org> Message-ID: <060.d6f2acc78fd671bf83b01dfc3a38936d@haskell.org> #8029: batch-mode recompilation checking sometimes fails -----------------------------+--------------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: recompilation, batch-mode Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -----------------------------+--------------------------------------------- Comment (by simonmar): There was one small suggestion to emerge from this discussion, namely to add the package name to the error message, but it was acknowledged that that wouldn't help in the instance that sparked the ticket. So is it worth keeping the ticket open? FWIW I don't think we should be looking for `.hs` files in one-shot compilation. As Ian says, there's no requirement that they have to be in a discoverable location at all, and it might break existing build systems to add that requirement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 09:38:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 09:38:37 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.94cdca74ad00fbb6e7585e01afe7a4c8@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by simonmar): I'm happy for this to go in, but please open new tickets for the remaining issues, and document the status in the release notes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 09:40:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 09:40:32 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.0364fb78aff25165899cc6784e105fe3@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by simonmar): Please add a reference to the ticket in the comment, and if you could add a sentence or two describing the problem (or a pointer to somewhere else that describes it) that would be really helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 10:30:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 10:30:45 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.6018e2625fb63526b18396b2e43b2d1b@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by awson): Not quite understood. ''a reference to the ticket in the comment...'' do you mean a source code comment? ''a sentence or two describing the problem...'' this should go to source code too? or to a comment to this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 11:14:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 11:14:46 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.5e68d67c78df3a5bac260cc9dee59068@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by edsko): * cc: edsko@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 16:25:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 16:25:13 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.0d8f8e143a5b68964b45ab717cdf68c3@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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 scpmw): > Unified code for symbol lookup (no more Win32 Sym* APIs vs Linux addr2line vs OS X / BSD atos) As far as the current design goes, we already read out the symbol and DWARF tables of all loaded executable sections. So by going through the RTS you'd have that part covered as well (well, at least for Linux). See [https://github.com/scpmw/ghc/blob/profiling-ncg/rts/Dwarf.c Dwarf.c]. > Mostly for profiling, where we'd like to inspect the program hundreds or even thousands of times per second with as little overhead as possible. I suppose you are talking about an external sampling routine that walks the stack in certain intervals? My approach would have been to try to do that in the RTS, but this might work as well. > Peter, do your DWARF improvements handle FFI calls (traversing from C back into Haskell)? I saw it work at least once - and when in doubt, the machinery for generating DWARF unwind from Cmm is flexible enough that there is probably a way to make it work if it doesn't already. Going from Haskell back to C is probably trickier. Bottom line is that even with with the points you mention, I am still a fan of the "leave it to the RTS"-approach. My main reason is that we already have (and need) quite a bit of functionality in the RTS, so having an external program re-implement stack walking and symbol lookup seems awkward to me. So maybe the solution here is to make the RTS more powerful. Could it be a possibility to use the mentioned libraries to displace libdwarf in the RTS? It's already a somewhat uncommon dependency, so if the switch would buy us unwinding of the C stack and better portability, it might work out quite nicely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 18:24:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 18:24:04 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.4139989186205f3c3cfc4948b038023e@haskell.org> #5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by monoidal): Just a section in `docs/users_guide/glasgow_exts` should be enough. Release notes are in `docs/users_guide/7.8.1-notes.xml`; Austin added the entry for pattern synonyms, you might expand it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 19:20:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 19:20:03 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.4e082047a2dd292eb229204c4f933ea9@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): by works i mean I've tested it :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 19:56:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 19:56:52 -0000 Subject: [GHC] #8692: when reporting missing modules, report them all at once Message-ID: <046.074c8ddb362d429fdfbacebb85a4a7ce@haskell.org> #8692: when reporting missing modules, report them all at once ------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, when a module is missing I get the message: {{{ Main.hs:6:18: Could not find module `Data.StorableVector.Base' It is a member of the hidden package `storablevector-0.2.8'. Perhaps you need to add `storablevector' to the build-depends in your .cabal file. It is a member of the hidden package `storablevector-0.2.8.1'. Perhaps you need to add `storablevector' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. }}} In order to solve the problem I add the package name to the Cabal file as suggested. However, if many modules are missing, then it becomes tedious to add every package individually and recompile with Cabal. It would be great if GHC shows _all_ missing modules and their according packages. This helps a lot when converting from the old Cabal style "recompile all library modules for an executable" to the new style "import the main library for every executable". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 19:57:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 19:57:02 -0000 Subject: [GHC] #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow In-Reply-To: <044.75a109ff49643f020ff0241cedbdd8c4@haskell.org> References: <044.75a109ff49643f020ff0241cedbdd8c4@haskell.org> Message-ID: <059.391569d97cc6786ad7b4794cd4f0c59f@haskell.org> #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow --------------------------------------------+------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.8.3 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 cdk): It looks like this has been resolved, `Data.Complex.magnitude` now uses `sqr z = z * z` and `GHC.Real` has rewrite rules for small, known constant exponents: https://github.com/ghc/packages-base/blob/master/Data/Complex.hs https://github.com/ghc/packages-base/blob/master/GHC/Real.lhs I found this bug on the list of 'getting started' bugs, but it's already been fixed. Time to close? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 21:45:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 21:45:26 -0000 Subject: [GHC] #8693: dyn way broken on powerpc Message-ID: <047.84ea3c5f16dbc4a0922607cee32ae1b1@haskell.org> #8693: dyn way broken on powerpc ----------------------------+---------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------- Building GHC with dynamic enabled I see lots of the following errors on powerpc (32 bit): {{{ [ 1679s] /tmp/ghc19669_0/ghc19669_6.s: Assembler messages: [ 1679s] [ 1679s] /tmp/ghc19669_0/ghc19669_6.s:39625:0: [ 1679s] Error: operand out of range (0x000000000000b700 is not between 0xffffffffffff8000 and 0x0000000000007fff) ... [ 1679s] /tmp/ghc19669_0/ghc19669_6.s:43936:0: [ 1679s] Error: operand out of range (0x0000000000008018 is not between 0xffffffffffff8000 and 0x0000000000007fff) [ 1679s] make[1]: *** [libraries/time/dist- install/build/Data/Time/Format.o] Error 1 [ 1679s] make[1]: *** Deleting file `libraries/time/dist- install/build/Data/Time/Format.o' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 22:12:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 22:12:26 -0000 Subject: [GHC] #8692: when reporting missing modules, report them all at once In-Reply-To: <046.074c8ddb362d429fdfbacebb85a4a7ce@haskell.org> References: <046.074c8ddb362d429fdfbacebb85a4a7ce@haskell.org> Message-ID: <061.f27636f385b6de6e8c9ff196a3598bc1@haskell.org> #8692: when reporting missing modules, report them all at once -------------------------------------+------------------------------------ Reporter: Lemming | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Already implemented in HEAD: #8322. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 22:29:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 22:29:42 -0000 Subject: [GHC] #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow In-Reply-To: <044.75a109ff49643f020ff0241cedbdd8c4@haskell.org> References: <044.75a109ff49643f020ff0241cedbdd8c4@haskell.org> Message-ID: <059.4fc966c1b77d01e2ad88034fb3cb5209@haskell.org> #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow --------------------------------------------+------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: You are right, I see that originally the bug was left open because of missing rewrite rules (https://github.com/ghc/packages- base/commit/d6adf6bd595c3b8f750acc9293f5847f176b521b) but they were added in #5237. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 23 22:41:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Jan 2014 22:41:50 -0000 Subject: [GHC] #8678: Derivin `Functor` complains about existential type In-Reply-To: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> References: <048.aa0a7629fe983b0a09239bcee6c385f2@haskell.org> Message-ID: <063.8cabf44b0c1b863a3dfc8c8172f6e2e3@haskell.org> #8678: Derivin `Functor` complains about existential type -------------------------------------+------------------------------------ Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): My guess is that the type of `Standard` is rewritten to `m ~ S n => a -> NonStandard m a` (which is existential in `n`). Simpler test case: `data A t a where A :: A Int a deriving Functor`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 01:27:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 01:27:23 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.0c9019548d26b9676192286812e80037@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): Thanks for sharing your patch. Here are some further comments: * The `EqualityT` constructor has type `Type -> Type -> Type`. Yet, this would prevent encoding constructs like `[t| ((~) Int) |]`, which should be valid. I recommend putting `EqualityT` in like `ArrowT` is now, as a nullary (0-argument) constructor. * The `foldM` and `go` algorithm (lines 65-67) you use seems like `repTapps`. Or, am I missing something? * In reifying an `IrredPred`, you use `splitAppTy`... but we're not sure there that the type is an application. For example, it could be a nullary type family, like this: {{{ type family ALittleSilly :: Constraint }}} I believe this would be an `IrredPred`, if there are no instances for the type family. (I haven't tested it.) I will say that I appreciate your attention to detail to GHC's coding style. I hope all these comments don't put you off -- we do really appreciate your contribution! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 03:34:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 03:34:27 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.783f96bb72d5bfc876ba35f8c3b4b11d@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): @austin Would you merge the two patches? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 06:48:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 06:48:17 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.888834e28340392029a7e10312c3ce86@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): I've made some improvements and simplifications based upon Austin's excellent feedback. the logic now correctly sets the haskell cpp-flags automatically when the selected cpp program is one of gcc, clang, or cpphs, and issues a warning if its a different program from those three and suggest explicitly setting --with-cpp-flags=FLAGS https://github.com/cartazio/ghc/compare/cpp_settings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 08:18:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 08:18:04 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.0457ae1c58300e0777d1367f11195a68@haskell.org> #5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by cactus): OK, will fix `7.8.1-notes.xml`. Just to avoid any misunderstandings, I've already added a section to `glasgow_exts.xml`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 08:54:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 08:54:43 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.cf25eea00f5cb53aed27638206cdd5c7@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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 blitzcode): This is all quite tricky since there seem to be so many different approaches to consider! ;-) For profiling, I am mostly coming at this problem from the perspective of already having an external tool that works for C/C++ and wanting to add Haskell support to it (it's a sampling profiler, pausing threads and capturing their stack, as you already said). I think you make a very valid point about already having all the functionality in the RTS (eventually). I don't have any technical / ideological reason to prefer an external profiler, what I'm after is seeing profiling data in realtime, while the program is running. If the RTS is collecting profiling data it could either provide some kind of IPC API to have an external tool collect it, or maybe just have a Haskell API so one could use a library like EKG to show it to the user. I couldn't really figure out how the Haskell to C stack transition works, but I think that's a less common case than the Haskell to C one anyway. Glad to hear that the latter seems to be working! I don't agree that having an external program do a stack walk is necessarily complicated or awkward. With your DWARF3 work, one should be able to use something like libunwind-ptrace (http://www.nongnu.org/libunwind/man/libunwind-ptrace%283%29.html) and have that functionality available without any custom work. For debugging, I think there's merit for an external tool. For RTS exceptions we're ok, but as soon as we have an actual segfault, some memory corruption has often already taken place. Any kind of stack traversal, symbol lookup and error reporting code will have a decent chance of failing itself due to a corrupted heap or such. The only library that I can think of would be libunwind. It's supported on Linux/BSD, Apple ships some kind of version of it on OS X (there are some limitations / issues with their port, IIRC), does DWARF2/3. It's not on Windows, but there's build-in support for stack walking through the DbgHelp library (StackWalk64, no idea if Windows PDB debug information supports the kind of wizardry your using to explain the STG stack to a DWARF3 debugger, though). It seems generating the right kind of debug symbols, and supporting and doing stack walking for Haskell & C/C++ on all three platforms is a major challenge... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 09:31:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 09:31:14 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.c770624f030364f2b3d4726a732522d4@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by simonmar): Yes, a source code comment in both cases please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 09:59:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 09:59:05 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.77919fafd1627e7b54243b6afb43e5f2@haskell.org> #2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.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 nomeata): > I?m not convinced about your solution. It seems a bit of a hack. I?m just re-reading this thread, and it seems that my proposed solution (replace `Coercible` in a rule with `~R#`, and inline `coercoe`) is precisely what we had concluded last week ? is that right or was there a misunderstanding on my side? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 14:32:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 14:32:28 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.e4514ca6c2c18d9616ad96a46b630643@haskell.org> #2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.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 nomeata): I looked into this and further cleaned up the branch. But I just cannot get it to optimize `map unsafeCoerce` away, and the problem seems to be not enough eta-expansion in the simplifier. So here is the rule as desugared; it has the shape that we want it to have {{{ ------ Local rules for imported ids -------- "map/coerce" [ALWAYS] forall (@ a) (@ b) ($r$dCoercible :: a GHC.Prim.~R# b). GHC.Base.map @ a @ b ((\ (tpl :: a) -> tpl) `cast` (_R -> ($r$dCoercible) :: (a -> a) ~# (a -> b))) = (\ (tpl :: [a]) -> tpl) `cast` (<[a]>_R -> [($r$dCoercible)]_R :: ([a] -> [a]) ~# ([a] -> [b])) }}} And here is the Core that we want it to match: {{{ GHC.Base.map @ GHC.Types.Int @ Test.Age ((Unsafe.Coerce.unsafeCoerce1 @ GHC.Types.Int @ Test.Age) `cast` (_R -> UnivCo representational GHC.Types.Int Test.Age :: (GHC.Types.Int -> GHC.Types.Int) ~# (GHC.Types.Int -> Test.Age))) }}} And for reference, here is the information on `unsafeCoerce1`: {{{ unsafeCoerce1 :: forall a b. a -> a {- Arity: 1, HasNoCafRefs, Strictness: , Unfolding: (\ @ a @ b x :: a -> x) -} }}} When trying to match, the matcher successfully matches the casts and then tries to match {{{ \ (tpl{v} [lid] :: a{tv aMF} [tv]) -> tpl{v} [lid] }}} against {{{ base:Unsafe.Coerce.unsafeCoerce1{v rKi} [gid] @ ghc-prim:GHC.Types.Int{(w) tc 3J} @ main:Test.Age{tc rM6} }}} It eta-expands both sides to match {{{ tpl{v} [lid] }}} against {{{ base:Unsafe.Coerce.unsafeCoerce1{v rKi} [gid] @ ghc-prim:GHC.Types.Int{(w) tc 3J} @ main:Test.Age{tc rM6} tpl{v} [lid] }}} and there it fails. Possible solutions: If GHC would inline `unsafeCoerce1` even though it is undersaturated, we?d be matching {{{ GHC.Base.map @ GHC.Types.Int @ Test.Age ((\ x :: GHC.Types.Int -> x) `cast` (_R -> UnivCo representational GHC.Types.Int Test.Age :: (GHC.Types.Int -> GHC.Types.Int) ~# (GHC.Types.Int -> Test.Age))) }}} which would succeed (this is also the shape we get from `map Age`). But I did not manage to define `unsafeCoerce` in a way that this happens. Alternatively, the matching code could, after eta-expanding, simplify the expression, so that the unfolding would happen here. Otherwise, my code is ready for review, see branch `wip/nomeata-T2110`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 16:17:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 16:17:40 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.778266780cb4d8bf9bbbe9b8191ea7ba@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Ok, here is a very different approach to solving the original problem of this ticket, namely making `foldl` a good consumer. Instead of trying hard to make the compiler sufficiently smart, why not help him a little bit? So here is what I did: I created a new magic function `oneShot` (similar to `lazy` etc.). Semantically, `oneShot = ? f ? x. f x", but the unfolding will put a `OneShot` on the binder for x. So essentially, it allows the programmer to tell the compiler: I promise I will only call this function once (and if I break my promise, I won?t blame you). So now one would define {{{ foldl k z xs = foldr (\v fn -> oneShot (\z -> fn (k z v))) id xs z }}} (because at this point, we know that the result of `foldr ... id xs` is ''not'' going to be used multiple times) and voil? ? good code: {{{ Foo.$wfoo :: GHC.Prim.Int# -> (# GHC.Types.Double, GHC.Types.Double #) [GblId, Arity=1, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 249 30}] Foo.$wfoo = \ (ww_s1ox :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.># 1 ww_s1ox) of _ [Occ=Dead] { GHC.Types.False -> letrec { $wgo_s1ot [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.Double# -> GHC.Prim.Double# -> (# GHC.Types.Double, GHC.Types.Double #) [LclId, Arity=3, Str=DmdType ] $wgo_s1ot = \ (w_s1oc :: GHC.Prim.Int#) (ww1_s1oj :: GHC.Prim.Double#) (ww2_s1oo :: GHC.Prim.Double#) -> case Foo.f (GHC.Types.I# w_s1oc) of _ [Occ=Dead] { Data.Complex.:+ ww8_aYl ww9_aYm -> case ww8_aYl of _ [Occ=Dead] { GHC.Types.D# ww11_s1sa -> case ww9_aYm of _ [Occ=Dead] { GHC.Types.D# ww13_s1sc -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.==# w_s1oc ww_s1ox) of _ [Occ=Dead] { GHC.Types.False -> $wgo_s1ot (GHC.Prim.+# w_s1oc 1) (GHC.Prim.+## ww1_s1oj ww11_s1sa) (GHC.Prim.+## ww2_s1oo ww13_s1sc); GHC.Types.True -> (# GHC.Types.D# (GHC.Prim.+## ww1_s1oj ww11_s1sa), GHC.Types.D# (GHC.Prim.+## ww2_s1oo ww13_s1sc) #) } } } }; } in $wgo_s1ot 1 0.0 0.0; GHC.Types.True -> (# Foo.foo1, Data.Complex.$fFloatingComplex1 #) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 18:29:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 18:29:10 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.c875ae6ea6790e986454fca032a00a1d@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): so as a way of "fuzzing" this patch, i'm trying out doing stuff like ./configure --with-gcc=clang --with-cpp=gcc and ./configure --with-gcc=gcc --with-cpp=cpphs and ./configure --with-gcc=gcc --with-cpp=clang (which is perhaps a bit daft, but seems to be a good way to understand what i'm not doing right for the build system :) ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 18:31:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 18:31:42 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.3209106fdaf7dd40a5fc16606a6b958b@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): so it seems i'm designing this a bit wrong, or at the very least, wrong for stage0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 18:34:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 18:34:02 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.f14d0cc620edcd8202b6839554f41389@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): here an error from ./configure --with-gcc=clang --with-cpp=gcc (where i try to add the cpp flags to mk/config.in with a patch i've not pushed yet) {{{ Writing new package config file... done. "inplace/bin/ghc-cabal" configure libraries/terminfo dist-boot "" --with- ghc="/usr/bin/ghc" --with-ghc-pkg="/usr/bin/ghc-pkg" --package- db=/Users/carter/Desktop/repoScratcher/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --disable-library- profiling --disable-shared --with- hscolour="/Users/carter/Library/Haskell/bin/HsColour" --configure- option=CFLAGS=" -m64 -fno-stack-protector " --configure-option=LDFLAGS=" -m64 " --configure-option=CPPFLAGS=" -m64 -E -undef -traditional " --constraint "Cabal == 1.18.1.3" --constraint "hpc == 0.6.0.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.0" --constraint "transformers == 0.3.0.0" --constraint "terminfo == 0.4.0.0" --with-gcc="gcc" --configure-option=--with-cc="gcc" --with-ar="/usr/bin/ar" --with-ranlib="ranlib" --with- alex="/Users/carter/Library/Haskell/bin/alex" --with- happy="/Users/carter/Library/Haskell/bin/happy" Configuring terminfo-0.4.0.0... configure: WARNING: unrecognized options: --with-compiler, --with-gcc checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/Users/carter/Desktop/repoScratcher/ghc/libraries/terminfo': configure: error: C compiler cannot create executables See `config.log' for more details make[1]: *** [libraries/terminfo/dist-boot/package-data.mk] Error 77 make: *** [all] Error 2 }}} with the associated log being {{{ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Haskell terminfo package configure 0.2, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --with-compiler=ghc CFLAGS= -m64 -fno-stack-protector LDFLAGS= -m64 CPPFLAGS= -m64 -E -undef -traditional --with-cc=gcc --with-gcc=/Users/carter/bin/gcc ## --------- ## ## Platform. ## ## --------- ## hostname = Carters-MacBook-Air.local uname -m = x86_64 uname -r = 13.0.0 uname -s = Darwin uname -v = Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 /usr/bin/uname -p = i386 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = Mach kernel version: Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 Kernel configured for up to 4 processors. 2 processors are physically available. 4 processors are logically available. Processor type: i486 (Intel 80486) Processors active: 0 1 2 3 Primary memory available: 4.00 gigabytes Default processor set: 183 tasks, 925 threads, 4 processors Load average: 1.99, Mach factor: 2.00 /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /Users/carter/.opam/system/bin PATH: /opt/local/bin PATH: /Users/carter/bin PATH: /usr/local/Cellar/smlnj/110.74/libexec/bin PATH: /Applications/Postgres.app/Contents/MacOS/bin PATH: /Users/carter/.scripts PATH: /Users/carter/Library/Haskell/bin PATH: /Users/carter/docTemplates PATH: /usr/local/share/npm/bin PATH: /usr/local/share/python PATH: /usr/local/Cellar/ruby/1.9.3-p194/bin PATH: /usr/local/bin PATH: /usr/local/sbin PATH: /usr/local/cuda/bin PATH: /usr/bin PATH: /bin PATH: /usr/sbin PATH: /sbin PATH: /usr/local/bin PATH: /opt/X11/bin PATH: /usr/texbin PATH: /usr/texbin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2117: checking for gcc configure:2144: result: gcc configure:2373: checking for C compiler version configure:2382: gcc --version >&5 i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2393: $? = 0 configure:2382: gcc -v >&5 Using built-in specs. Target: i686-apple-darwin11 Configured with: /Volumes/Media/Builds/gcc-5666.3/build/obj/src/configure --disable-checking --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++,fortran --program-transform- name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple- darwin11 --program-prefix=i686-apple-darwin11- --host=x86_64-apple- darwin11 --target=i686-apple-darwin11 --with-gxx-include- dir=/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) configure:2393: $? = 0 configure:2382: gcc -V >&5 gcc-4.2: argument to `-V' is missing configure:2393: $? = 1 configure:2382: gcc -qversion >&5 i686-apple-darwin11-gcc-4.2.1: no input files configure:2393: $? = 1 configure:2413: checking whether the C compiler works configure:2435: gcc -m64 -fno-stack-protector -m64 -E -undef -traditional -m64 conftest.c >&5 # 1 "conftest.c" # 1 "" # 1 "" # 1 "conftest.c" int main () { ; return 0; } configure:2439: $? = 0 configure:2477: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "Haskell terminfo package" | #define PACKAGE_TARNAME "terminfo" | #define PACKAGE_VERSION "0.2" | #define PACKAGE_STRING "Haskell terminfo package 0.2" | #define PACKAGE_BUGREPORT "judah dot jacobson at gmail dot com" | #define PACKAGE_URL "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2482: error: in `/Users/carter/Desktop/repoScratcher/ghc/libraries/terminfo': configure:2484: error: C compiler cannot create executables See `config.log' for more details ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set=set ac_cv_env_CFLAGS_value=' -m64 -fno-stack-protector ' ac_cv_env_CPPFLAGS_set=set ac_cv_env_CPPFLAGS_value=' -m64 -E -undef -traditional ' ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_LDFLAGS_set=set ac_cv_env_LDFLAGS_value=' -m64 ' ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_prog_ac_ct_CC=gcc ## ----------------- ## ## Output variables. ## ## ----------------- ## CC='gcc' CFLAGS=' -m64 -fno-stack-protector ' CPP='' CPPFLAGS=' -m64 -E -undef -traditional ' DEFS='' ECHO_C='\c' ECHO_N='' ECHO_T='' EGREP='' EXEEXT='' GREP='' LDFLAGS=' -m64 ' LIBOBJS='' LIBS='' LTLIBOBJS='' OBJEXT='' PACKAGE_BUGREPORT='judah dot jacobson at gmail dot com' PACKAGE_NAME='Haskell terminfo package' PACKAGE_STRING='Haskell terminfo package 0.2' PACKAGE_TARNAME='terminfo' PACKAGE_URL='' PACKAGE_VERSION='0.2' PATH_SEPARATOR=':' SHELL='/bin/sh' TERMINFO_INCLUDES='' TERMINFO_INCLUDE_DIRS='' TERMINFO_LIB='' TERMINFO_LIB_DIRS='' ac_ct_CC='gcc' bindir='${exec_prefix}/bin' build_alias='' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='NONE' host_alias='' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='NONE' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ----------- ## ## confdefs.h. ## ## ----------- ## /* confdefs.h */ #define PACKAGE_NAME "Haskell terminfo package" #define PACKAGE_TARNAME "terminfo" #define PACKAGE_VERSION "0.2" #define PACKAGE_STRING "Haskell terminfo package 0.2" #define PACKAGE_BUGREPORT "judah dot jacobson at gmail dot com" #define PACKAGE_URL "" configure: exit 77 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 18:50:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 18:50:16 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.31a199e8a265650627c94cc8213c6999@haskell.org> #5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by thoughtpolice): Thanks Gergo! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 20:22:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 20:22:02 -0000 Subject: [GHC] #8694: ghc -M doesn't handle addDependentFile or #included files Message-ID: <047.ce71b4022a36793f3d6cf75411ff19f9@haskell.org> #8694: ghc -M doesn't handle addDependentFile or #included files ------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- ghc -M doesn't emit dependencies specified by TH's `addDependentFile`, not does it emit dependencies for `#include`d files. The former is quite hard to do, because it requires compiling the code: we only have the information about `addDependentFile` calls after compilation. So in order to fix this, `ghc -c` would have to drop some information somewhere for the build system to pick up. In theory we should only have to preprocess files to get the list of #included files, and ghc -M already preprocesses all the files. However, currently #included files are picked up by the lexer during parsing, so fixing this isn't trivial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 24 21:36:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Jan 2014 21:36:49 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) Message-ID: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/haskell2010 | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- According to the documentation for Data.Int, ?All arithmetic is performed modulo 2!^n, where n is the number of bits in the type.? However, this promise is broken by the following exception: {{{ Prelude> (minBound :: Int) `quot` (-1) *** Exception: arithmetic overflow }}} (This also occurs with Int8, Int16, Int32, and Int64, and likewise for `div`.) If all arithmetic is performed modulo 2!^n, I would rather expect the above to evaluate to `minBound`, since after all `minBound * (-1) == minBound`. The fact that an exception is raised adds an unnecessary burden in pure code to ensure `quot` (or `div`) is never called with these specific arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 01:09:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 01:09:24 -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.0dcde3f06196486ebb3d93e29314634a@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by lerkok): * cc: erkokl@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 01:12:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 01:12:12 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' Message-ID: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' ----------------------------------+------------------------------ Reporter: Kata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------ Building ekmett's lens package from HEAD (revision 80c1fddf) with the following error fragment: {{{ Last 10 lines of the build log ( /home/kata/.cabal/logs/lens-4.0.log ): [77 of 85] Compiling Data.Vector.Lens ( src/Data/Vector/Lens.hs, dist/build/Data/Vector/Lens.o ) [78 of 85] Compiling Data.Vector.Generic.Lens ( src/Data/Vector/Generic/Lens.hs, dist/build/Data/Vector/Generic/Lens.o ) [79 of 85] Compiling Generics.Deriving.Lens ( src/Generics/Deriving/Lens.hs, dist/build/Generics/Deriving/Lens.o ) [80 of 85] Compiling GHC.Generics.Lens ( src/GHC/Generics/Lens.hs, dist/build/GHC/Generics/Lens.o ) [81 of 85] Compiling System.Exit.Lens ( src/System/Exit/Lens.hs, dist/build/System/Exit/Lens.o ) [82 of 85] Compiling System.FilePath.Lens ( src/System/FilePath/Lens.hs, dist/build/System/FilePath/Lens.o ) [83 of 85] Compiling System.IO.Error.Lens ( src/System/IO/Error/Lens.hs, dist/build/System/IO/Error/Lens.o ) /usr/bin/ld: dist/build/Control/Lens/TH.dyn_o: relocation R_X86_64_PC32 against undefined symbol `lenszm4zi0_ControlziLensziInternalziTH_appsE1zulgo_info' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status cabal: Error: some packages failed to install: lens-4.0 failed during the building phase. The exception was: ExitFailure 1 }}} Full log is attached. I'm not trying to build with shared libraries, or profiling, or anything like that. I can reproduce this failure starting from a fresh Debian testing install as follows: 1. Bootstrap GHC HEAD. {{{ sudo aptitude install ghc=7.6.3-6 happy=1.19.0-1 alex=3.1.0-1 sudo apt-get build-dep ghc cd /var/tmp git clone git://git.haskell.org/ghc.git cd ghc git checkout e01367ff ./sync-all get ./boot ./configure # Adjust the -j option to taste. make -j4 sudo make install }}} 2. Bootstrap cabal-install. {{{ cd /var/tmp wget http://www.haskell.org/cabal/release/cabal-install-1.18.0.2/cabal- install-1.18.0.2.tar.gz -O - | tar xzf - cd cabal-install-1.18.0.2 patch -p3 < cabal-install-ghc-HEAD.patch # see attached sudo aptitude install zlib1g-dev ./bootstrap.sh export PATH=$HOME/.cabal/bin:$PATH cabal update }}} 3. Build lens. {{{ cd /var/tmp git clone https://github.com/ekmett/lens cd lens git checkout 80c1fddf cabal install cpphs cabal install # this fails }}} Using gcc Debian 4.8.2-14, ld 2.24. The GHC fingerprint and output of `ghc --info` is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 01:21:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 01:21:35 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.ab44d0962995cf3fa2a2f111c93123a5@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by Kata): Weirdly, if I run `cabal install` again after the failure, it seems to succeed. I don't know whether it actually succeeded or if it's just lying to me and will blow up in my face at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 01:40:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 01:40:02 -0000 Subject: [GHC] #8697: Type rationals Message-ID: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> #8697: Type rationals ------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've used GHC's Type Nats to implement my own type level rationals (code below). This works fine, but the syntax is a little funky because you have to write out the number as a fraction. For example, you must write 13/10 instead of 1.3; or even worse, 13/1 instead of 13. It would be nice to just write the decimal notation. I only see one potential problem with this feature: the dot in the decimal notation could interfere with the dot in forall statements. I guess this can be parsed unambiguously, but maybe not. {{{ data Frac = Frac Nat Nat data instance Sing (n::Frac) = SFrac Integer Integer instance (SingI a, SingI b) => SingI ('Frac a b) where sing = SFrac (fromSing (sing :: Sing a)) (fromSing (sing :: Sing b)) instance Fractional r => SingE (Kind :: Frac) r where fromSing (SFrac a b) = fromIntegral a/fromIntegral b type (/) a b = 'Frac a b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 09:17:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 09:17:03 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci Message-ID: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci ----------------------------------+------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- When fixing #7134 I've found .ctors section handling does not work on 64-bit Windows ghci. Patch https://ghc.haskell.org/trac/ghc/attachment/ticket/7134/ghc- w64fix.patch now disables .ctor handling for 64-bit Windows ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 09:33:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 09:33:07 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.85f06634a9400cc2fab9fae08f5e1b9f@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): https://ghc.haskell.org/trac/ghc/attachment/ticket/7134/ghc-w64fix.patch is updated to mark relevant places with the number of this ticket (#8698). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 10:01:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 10:01:09 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.77ec44f626112698e1a295f11f19cc0b@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+---------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by ezyang): * cc: ezyang (added) * owner: => ezyang Comment: Can you upload the object file in question? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 10:04:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 10:04:34 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.bd33c972a67d1838d31002974fcd0376@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): I've updated the patch for HEAD. Now: 1. Memory for trampolines is reserved right next to memory for image. We reserve this space for all symbols in image. This could look as overkill, but this is the way it is done in unixish cases, and also {{{VirtualAlloc}}} takes physical memory from system lazily (only when relevant page is accessed), and we don't need to save virtual space because we have plenty of it. Unlike in unixish cases, though, we avoid any reallocations because we can take the number of symbols from PECoff header. 2. Loading of archives is fixed. Looking into the code I can say it never worked for static GHCi linker on Win64. Now it works. Don't try to remove prelinked HSbase-4.7.0.0.o though :) otherwise ghci segfaults trying to set buffering status for base's stdin, stdout and stderr. I suspect, this is related to the way {{{initInterpBuffering}}} in {{{GhciMonad.hs}}} works. 3. Disabled {{{.ctor}}} handling comments now contain the number of related ticket, which I've created for this. 4. The status is documented in release notes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 10:23:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 10:23:05 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.17e03ec285dd2039e852fadcccb9a96c@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+---------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 10:35:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 10:35:03 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.b89ba6b7fb24173ef632804a5dfaa920@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+---------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): Also, it might be necessary to add {{{RTS_WIN64_ONLY(SymI_HasProto(FreeEnvironmentStringsW))}}} to {{{RTS_MINGW_ONLY_SYMBOLS}}} definition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 10:53:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 10:53:11 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.2b55b62a81c34df0ce74f27906b038f9@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by awson): I've updated the patch (added a reference to the ticket and updated the comment). See also my explanation here: https://ghc.haskell.org/trac/ghc/ticket/7097#comment:19. Btw, with this patch we don't need to fix mingw-w64 (or any other) headers anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 14:58:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 14:58:04 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.777124ccb640fef7b63f2a256a6a1a64@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Fuuzetsu): How do you propose 1/3 is shown with decimal notation? Would this mean there are two different notations around? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 18:08:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 18:08:56 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.09c6e8264b2a4ce2f43f34ac6ae5ffc5@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): [https://github.com/bgamari/ghc/compare/disable-ld Here] is a patch set to ensure that people aren't bitten by this. We sacrifice support for binutils' ld when dynamic linking on ARM but at least people don't encounter random segfaults. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 18:44:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 18:44:46 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.c193a888e559e4079524226da7c5f22f@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): HVR also shared a wee patch that may be needed for some of the cleanup on this http://lpaste.net/99054 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 18:52:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 18:52:20 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.1990e49cd7262b42161b2571bf353424@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by joelteon): It seems like this patch hardcodes /usr/bin/gcc to be the compiler during the build of in-tree ghc-pwd, which results in a lot of build-related headaches on OSX, since /usr/bin/gcc is clang pretending to be gcc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 25 19:00:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Jan 2014 19:00:34 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.3eef49f859b802437ad0543f67c8fb75@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): {{{ carter repoScratcher/ghc ?cpp_settings*? ? ag /usr/bin/gcc compiler/main/SysTools.lhs 154: extra_ghc_opts = ["-pgmc/usr/bin/gcc","-pgml${topdir}/bin/unlit", ... etc.], mk/config.mk.in 619:# AC_PROG_CPP defines CPP as "/usr/bin/gcc -E" rts/ghc.mk 526:# gcc as its preprocessor. If gcc isn't at /usr/bin/gcc, or we need }}} gives some fixme locations @joelton, sounds like your test build was just with master, Try the CPP settings branch WIP :) (mind you, still broken, but maybe less so than unpatched would be) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 02:50:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 02:50:55 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.6110ee543dc17a3cf3c5d5daeb097bcb@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by rwbarton): I looked into this a bit (with `cabal install --ghc-option=-v3 -v -v -v`) and it looks like * there are (at least) two modules in `lens` which use Template Haskell, `Control.Lens.At` and `System.IO.Error.Lens` * when building the first one `Control.Lens.At`, ghc correctly links the modules it needs to run the TH into a little shared library * when building the second one `System.IO.Error.Lens`, ghc doesn't include any modules (I only did a couple spot checks here, but) that were built before `Control.Lens.At` when building the shared library for TH. In particular, it includes `Control.Lens.TH` but not `Control.Lens.Internal.TH` which the former depends on. I didn't attempt to investigate in the source code why this is happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 04:18:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 04:18:17 -0000 Subject: [GHC] #5144: Pattern synonyms In-Reply-To: <046.358306463908294bbc35edfc129eeda7@haskell.org> References: <046.358306463908294bbc35edfc129eeda7@haskell.org> Message-ID: <061.94efa410e6b4b11d9df1a8f0370c31f1@haskell.org> #5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by cactus): The source of the confusion over the docs was that I forgot to push my commit that added the section to `glasgow_exts`. Now I've pushed a commit that adds both that and cleans up the release notes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 04:22:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 04:22:18 -0000 Subject: [GHC] #8699: Multiple test faliures on 32-bit Linux systems. Message-ID: <047.0a18fb8eba467de4cead3e8638814c85@haskell.org> #8699: Multiple test faliures on 32-bit Linux systems. ----------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- I ran validate with HEAD (e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19) on 3 different 32-bit Linux boxes and I'm seeing different failures on each one. I was advised on IRC to create a ticket with all the failures. The first and third box are using the binary of 7.6.3 provided on the GHC site. I had to link libgmp.so.3 to libgmp.so.10 on both of these in order to get it to install properly. Please ask about any info that I have not provided below! First box: {{{Linux misaki 3.12.3-gentoo #2 SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.0 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.0, (c) 2003 Chris Dornan and Simon Marlow}}} {{{ lrwxrwxrwx 1 root root 16 Oct 14 04:24 /usr/lib/libgmp.so.10 -> libgmp.so.10.1.3 lrwxrwxrwx 1 root root 12 May 31 2013 /usr/lib/libgmp.so.3 -> libgmp.so.10 }}} The full log is at [1]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="T1969 haddock.Cabal haddock.base" OVERALL SUMMARY for test run started at Sun Jan 26 03:26:36 2014 GMT 0:19:58 spent to go through 3883 total tests, which gave rise to 15172 test cases, of which 11625 were skipped 28 had missing libraries 3458 expected passes 58 expected failures 3 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T1969 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) }}} As discussed on the mailing list, the Haddock numbers still need tweaking even after Austin updated them the other day. T1969 failure seems to come and go. ---- Second box: {{{Linux yuuki 3.11.4-gentoo #1 SMP Tue Oct 8 00:19:37 BST 2013 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow}}} I installed the bootstrapping compiler on this box from Gentoo's package manager so I'm not sure how gmp is linked here. I can retry by boostrapping from binary and linking libgmp.3 to libgmp.10 (like the other boxes did) for consistency. The version of this complier is 7.6.3-r1. The full log is at [2]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="T1969 haddock.compiler T7859" OVERALL SUMMARY for test run started at Sun Jan 26 03:34:47 2014 GMT 0:12:04 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3453 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) runghc T7859 [bad stderr] (normal) }}} A different Haddock perf failure, T1969 seems to have failed again and a totally new failure, T7859. ---- Third box: {{{Linux lenalee 3.11.4-gentoo #1 SMP Mon Oct 7 19:19:00 BST 2013 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow}}} {{{ lrwxrwxrwx 1 root root 9 Jan 26 02:42 /usr/lib/libgmp.so.3 -> libgmp.so lrwxrwxrwx 1 root root 16 Nov 20 11:54 /usr/lib/libgmp.so -> libgmp.so.10.1.3 }}} The full log is at [3]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="hsc2hs004 T3837 haddock.compiler haddock.base T3307 environment001 T1969 gadt23 Capi_Ctype_001 Capi_Ctype_002" OVERALL SUMMARY for test run started at Sun Jan 26 03:28:47 2014 GMT 0:10:37 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3446 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 10 unexpected failures Unexpected failures: ../../libraries/base/tests/IO T3307 [bad stderr] (normal) ../../libraries/base/tests/IO environment001 [bad stderr] (normal) ffi/should_run Capi_Ctype_001 [bad stderr] (normal) ffi/should_run Capi_Ctype_002 [bad stderr] (normal) gadt gadt23 [bad stderr] (normal) hsc2hs T3837 [bad stderr] (normal) hsc2hs hsc2hs004 [bad stderr] (normal) perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) }}} Whole plethora of failures! Haddock numbers again and a bunch of other stuff. Considering how close 7.8 is, I think these should be looked at (especially that last set doesn't look too good). I notice that over 2000 more tests were skipped on the first box (this is my day-to-day use computer). How are the tests to be skipped determined? [1]: http://fuuzetsu.co.uk/misc/validate-misaki- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 [2]: http://fuuzetsu.co.uk/misc/validate-yuuki- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 [3]: http://fuuzetsu.co.uk/misc/validate-lenalee- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 04:54:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 04:54:12 -0000 Subject: [GHC] #8699: Multiple test faliures on 32-bit Linux systems. In-Reply-To: <047.0a18fb8eba467de4cead3e8638814c85@haskell.org> References: <047.0a18fb8eba467de4cead3e8638814c85@haskell.org> Message-ID: <062.438dfefd98f5f3967b9c9f5f2c5c7729@haskell.org> #8699: Multiple test faliures on 32-bit Linux systems. -------------------------------------+----------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by Fuuzetsu): Oops, regarding that third box, it seems that some stderr failures were caused by `distcc` getting into my PATH when it shouldn't have. Here's the result of `make test` with that moved out of the way: {{{ Unexpected results from: TEST="haddock.compiler haddock.base T1969 T3064" OVERALL SUMMARY for test run started at Sun Jan 26 04:30:11 2014 GMT 0:18:05 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3452 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 4 unexpected failures Unexpected failures: perf/compiler T1969 [stat too good] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) }}} and here's the log of that `make test` run: http://fuuzetsu.co.uk/misc/validate-lenalee- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19-tests-nodistcc So overall it seems that the Haddock numbers and T1969 are the frequently failing things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 06:49:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 06:49:48 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.1110091105919140a6c8dcddb9711d71@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by awson): I've updated the patch: {{{__imp_}}} could be perfectly legal part of identifier and we can link potentially wrong function here. So we issue corresponding warning if this occurs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 08:19:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 08:19:01 -0000 Subject: [GHC] #7593: Unable to print exceptions of unicode identifiers In-Reply-To: <044.180348374c60284a01c4dfa59f341d42@haskell.org> References: <044.180348374c60284a01c4dfa59f341d42@haskell.org> Message-ID: <059.26caade37ba8ea2d4cca7b6f0d9e8157@haskell.org> #7593: Unable to print exceptions of unicode identifiers -------------------------------------------------+------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by huzhe): I believe this is the same issue as this: {{{ Prelude> putStrLn "?" *** Exception: : hPutChar: invalid argument (invalid character) Prelude> }}} This doesn't happen with Latin-1 characters like "?" on my machine (codepage dependency?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 09:12:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 09:12:02 -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.07be08370291ca8cd6d16295504271d7@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by hvr): Replying to [ticket:8695 rleslie]: > The fact that an exception is raised adds an unnecessary burden in pure code to ensure `quot` (or `div`) is never called with these specific arguments. Fwiw, you also have to avoid calling `quot`/`div` with a `0`-divisor, otherwise a div-by-zero exception is raised. I wonder if this isn't rather a deficiency of the Haskell2010 report, failing to mention that the modulo-semantics make an exception for the `quot`/`div` operations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 09:58:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 09:58:18 -0000 Subject: [GHC] #8700: Cross-compilation perf-cross BuildFlavour Message-ID: <045.36b67841d294a8aac5cdb12bc24ba0a0@haskell.org> #8700: Cross-compilation perf-cross BuildFlavour -------------------------------------------+------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Adds a perf-cross BuildFlavour to build.mk.sample in preparation for release-ready builds of GHC iOS cross compilers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 10:08:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 10:08:48 -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.a25830ad9a5ef961b59cbfdf96be85af@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by rleslie): Replying to [comment:2 hvr]: > Fwiw, you also have to avoid calling `quot`/`div` with a `0`-divisor, otherwise a div-by-zero exception is raised. I wonder if this isn't rather a deficiency of the Haskell2010 report, failing to mention that the modulo-semantics make an exception for the `quot`/`div` operations. I think a division-by-zero exception is reasonably well-understood, since there is no value {{{q = d `quot` 0}}} that could be returned in general such that `q * 0 == d`, even with modulo arithmetic. Most code performing division with arbitrary operands is well aware of the possibility of a division-by-zero exception, and defensively avoids it. Much less well known or understood, I think, is the possibility of overflow from the singular case of {{{minBound `quot` (-1)}}} which, if not accounted for, can also break one?s application (and possibly be a vector for denial-of-service attacks?) I think I?d much rather have {{{minBound `quot` (-1) == minBound}}} under modulo arithmetic than a justification for the current exception. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 10:21:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 10:21:10 -0000 Subject: [GHC] #8701: Update libffi-tarballs to latest libffi Message-ID: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> #8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- libffi 3.0.14 contains fixes necessary for successful iOS (and probably ARM in general) cross-compilation. I've created a new archive that can be dropped in to replace the current libffi-tarballs archive here: https://github.com/ghc-ios/libffi- tarballs/blob/master/libffi-3.0.14.tar.gz?raw=true -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 12:17:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 12:17:15 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.2a144f8b8727eec4ce9b90b8411499cd@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Hmm, it seems that the oneShot-information is thrown away before generating the interface, so the use of `oneShot` does not help across module boundaries for now; this is the unfolding {{{ foldl :: forall a b. (b -> a -> b) -> b -> [a] -> b {- Arity: 3, HasNoCafRefs, Strictness: , Inline: INLINE (sat-args=3), Unfolding: InlineRule (3, False, False) (\ @ a @ b k :: b -> a -> b z :: b xs :: [a] -> GHC.Base.foldr @ a @ (b -> b) (\ ds :: a ds1 :: b -> b tpl :: b -> ds1 (k tpl ds)) (GHC.Base.id @ b) xs z) -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 12:30:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 12:30:15 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.e2e1833ad6b1edcd7a4ed88dd599e18b@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): The trick with `oneShot` is neat, and it works for `foo x = sum $ [f i | i <- [1 .. x]]` and `foo x = sum $ [f i | i <- [1 .. x] , odd i ]` (note the filter), but does not yield optimal code for nested iterations like `foo x = sum $ concat [[f i | i <- [1 .. n]]| n <- [1..x]]`, where we get: {{{ letrec { go_a1mU [Occ=LoopBreaker] :: GHC.Prim.Int# -> Data.Complex.Complex GHC.Types.Double -> Data.Complex.Complex GHC.Types.Double [LclId, Arity=1, Str=DmdType ] go_a1mU = \ (x_a1mV :: GHC.Prim.Int#) -> let { n_X1nv :: Data.Complex.Complex GHC.Types.Double -> Data.Complex.Complex GHC.Types.Double [LclId, Str=DmdType] n_X1nv = case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.==# x_a1mV ww_s1ro) of _ [Occ=Dead] { GHC.Types.False -> go_a1mU (GHC.Prim.+# x_a1mV 1); GHC.Types.True -> GHC.Base.id @ (Data.Complex.Complex GHC.Types.Double) } } in case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.># 1 x_a1mV) of _ [Occ=Dead] { GHC.Types.False -> letrec { go1_X1nG [Occ=LoopBreaker] :: GHC.Prim.Int# -> Data.Complex.Complex GHC.Types.Double -> Data.Complex.Complex GHC.Types.Double [LclId, Arity=2, Str=DmdType ] go1_X1nG = \ (x1_X1nI :: GHC.Prim.Int#) (eta_B1 :: Data.Complex.Complex GHC.Types.Double) -> let { a_s1pu [Dmd=] :: Data.Complex.Complex GHC.Types.Double [LclId, Str=DmdType] a_s1pu = case eta_B1 of _ [Occ=Dead] { Data.Complex.:+ ww2_a10M ww3_a10N -> case ww2_a10M of _ [Occ=Dead] { GHC.Types.D# ww5_s1ub -> case ww3_a10N of _ [Occ=Dead] { GHC.Types.D# ww7_s1ud -> case Foo.f (GHC.Types.I# x1_X1nI) of _ [Occ=Dead] { Data.Complex.:+ ww9_a10Z ww10_a110 -> case ww9_a10Z of _ [Occ=Dead] { GHC.Types.D# ww12_s1uf -> case ww10_a110 of _ [Occ=Dead] { GHC.Types.D# ww14_s1uh -> Data.Complex.:+ @ GHC.Types.Double (GHC.Types.D# (GHC.Prim.+## ww5_s1ub ww12_s1uf)) (GHC.Types.D# (GHC.Prim.+## ww7_s1ud ww14_s1uh)) } } } } } } } in case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.==# x1_X1nI x_a1mV) of _ [Occ=Dead] { GHC.Types.False -> go1_X1nG (GHC.Prim.+# x1_X1nI 1) a_s1pu; GHC.Types.True -> n_X1nv a_s1pu }; } in go1_X1nG 1; GHC.Types.True -> n_X1nv }; } in go_a1mU 1 Foo.foo1; }}} I guess we?d want `n_X1nv` to have arity one here, and be eta-expanded, so that it turns into a join-point, do we? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 13:38:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 13:38:25 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.6f2eb950e29e057fd350ee244cd39249@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by trommler): Replying to [comment:16 carter]: OK, I see what the issue is: > here an error from > ./configure --with-gcc=clang --with-cpp=gcc > > (where i try to add the cpp flags to mk/config.in with a patch i've not pushed yet) > > [...] > with the associated log being > > {{{ > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by Haskell terminfo package configure 0.2, which was > generated by GNU Autoconf 2.69. Invocation command line was > > $ ./configure --with-compiler=ghc CFLAGS= -m64 -fno-stack-protector LDFLAGS= -m64 CPPFLAGS= -m64 -E -undef -traditional --with-cc=gcc --with-gcc=/Users/carter/bin/gcc > > [...] > configure:2413: checking whether the C compiler works > configure:2435: gcc -m64 -fno-stack-protector -m64 -E -undef -traditional -m64 conftest.c >&5 >[...] > }}} {{{$CPPFLAGS}}} will be used in compiler commands too. The compiler command configure tests is something like {{{$CC $CFLAGS $CPPFLAGS $LDFLAGS}}}. {{{-E}}} must not be part of CPPFLAGS but CPP should be set to {{{$CC -E}}} unless you specify the preprocessor ({{{/usr/bin/cpp}}} on my system) directly. If you call the preprocessor through a compiler driver like {{{gcc}}} or {{{clang}}} then {{{$CPP}}} should include the {{{-E}}} flag. I think the user should be required to specify {{{--with-cpp="gcc -E"}}} rather than {{{--with-cpp=gcc}}} and likewise for clang. I'll prepare a new pull request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 13:41:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 13:41:14 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.2047ef2254cb8ed629b61825c0f8e3e1@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Interesting: Even without the `oneShot` marker surviving the unfolding, nofib shows some extreme changes in allocations: {{{ Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- bernouilli +0.1% -4.2% 0.12 0.12 +0.0% fft2 +0.0% +125.4% 0.04 0.05 +0.0% gen_regexps +0.0% -9.4% 0.00 0.00 +0.0% integrate +0.1% +144.2% 0.14 0.14 +1.0% minimax +0.0% -3.8% 0.00 0.00 +0.0% simple +0.1% -7.5% 0.15 0.15 -14.7% x2n1 +0.1% -45.2% 0.00 0.00 -50.0% -------------------------------------------------------------------------------- Min -0.9% -45.2% -27.5% -27.7% -50.0% Max +0.2% +144.2% +3.1% +3.1% +100.0% Geometric Mean +0.0% +0.8% -5.9% -5.7% -0.3% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 13:57:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 13:57:17 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.be5befb2efa89fcd7d688e0d39cfe7de@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by trommler): Replying to [comment:20 trommler]: > Replying to [comment:16 carter]: > OK, I see what the issue is: > > here an error from > > ./configure --with-gcc=clang --with-cpp=gcc > > > > (where i try to add the cpp flags to mk/config.in with a patch i've not pushed yet) > > > > [...] > > with the associated log being > > > > {{{ > > This file contains any messages produced by compilers while > > running configure, to aid debugging if configure makes a mistake. > > > > It was created by Haskell terminfo package configure 0.2, which was > > generated by GNU Autoconf 2.69. Invocation command line was > > > > $ ./configure --with-compiler=ghc CFLAGS= -m64 -fno-stack-protector LDFLAGS= -m64 CPPFLAGS= -m64 -E -undef -traditional --with-cc=gcc --with-gcc=/Users/carter/bin/gcc > > > > [...] > > configure:2413: checking whether the C compiler works > > configure:2435: gcc -m64 -fno-stack-protector -m64 -E -undef -traditional -m64 conftest.c >&5 > >[...] > > }}} Wait a minute! Why are those flags passed to the C compiler at all. I thought they were meant to be used by ghc to preprocess Haskell files?! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 15:33:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 15:33:17 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.49d6f607fa6ea3d8e208d62da7efd547@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): *bump* Any ideas as to why GHC isn't applying the rule in `main8`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 17:21:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 17:21:44 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.e0972d876b8ad39bd2d82daec577cb1b@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): @trommler, hrmmmm I was doing the command + flag design because that maps to the current GHC dynflags model, perhaps it'd be better to have distinct CPP programs for C and Haskell in the build model? Does this mean they should be disjoint in GHC's dynflags too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 17:25:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 17:25:45 -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.648fc689debda614d60d08f4205a9e77@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by carter): @rleslie any changes need to have clear meaning! For example, why would minBound * (-1) == minBound? Is this an artifact of twos-complement? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 18:09:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 18:09:45 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.13499295831fe31cb233e33bd15e01cc@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by trommler): Replying to [comment:22 carter]: > @trommler, hrmmmm > > I was doing the command + flag design because that maps to the current GHC dynflags model, ... and I tried to set {{{gcc -E}}} for cpp and failed. GHC tries to exec {{{gcc -E}}} then and that does not exist. We could fix that by parsing CPP in configure (once) or in GHC (at every invocation) or stick with your original design (which I did for now in my branch). > > perhaps it'd be better to have distinct CPP programs for C and Haskell in the build model? I think, yes. I don't fully understand what {{{--with-gcc}}} is supposed to do. It changes the C compiler half way through configure and then even sets {{{CC}}}. The wiki says it specified the compiler used to compile C files but GHC will use its own C compiler. To me that sounds like we should actually set the C compiler using {{{CC=}}} on the configure command line. But I might be missing a major issue here. > Does this mean they should be disjoint in GHC's dynflags too? Do you mean there should be another set of CPP and CPPFLAGS for C files? I don't think so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 18:51:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 18:51:57 -0000 Subject: =?utf-8?q?=5BGHC=5D_=238702=3A_floor=2C_ceiling=2C_truncate_and_?= =?utf-8?q?so_on=E2=80=A6_on_NaN_fail?= Message-ID: <046.bfb06deedd309077ba335cb50d219c1e@haskell.org> #8702: floor, ceiling, truncate and so on? on NaN fail -------------------------+------------------------------------------------- Reporter: | Owner: skypers | Status: new Type: bug | Milestone: _|_ Priority: high | Version: 7.4.1 Component: | Operating System: Linux libraries/base | Type of failure: Incorrect result at runtime Keywords: | Test Case: let nan = 0 / 0 in floor nan Architecture: | Blocking: x86_64 (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Those functions returns a total random value when given NaN. This is not an acceptable behavior I guess, and we might inquire on what to do. For instance: {{{ let nan = 0 / 0 in floor nan }}} result: {{{ -269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907719574457253034494436336205824 }}} Maybe an arithmetic exception would be a better behavior? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 21:32:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 21:32:30 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.1229b81b71f2cd671ae4d0b2c132746d@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------ Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Feuerbach): * cc: roma@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 22:39:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 22:39:59 -0000 Subject: [GHC] #3202: Make XNoMonomorphismRestriction the default in GHCi In-Reply-To: <047.d2e31e41b925b8804676d46611405d7d@haskell.org> References: <047.d2e31e41b925b8804676d46611405d7d@haskell.org> Message-ID: <062.e8653f98103192dd47f4d26e364bcb08@haskell.org> #3202: Make XNoMonomorphismRestriction the default in GHCi -------------------------------------+------------------------------------ Reporter: YitzGale | Owner: pcapriotti Type: feature request | Status: closed Priority: high | Milestone: 7.6.1 Component: GHCi | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3217 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Krzysztof Gogolewski ): In [changeset:"73250400ef628126aea9ebff7dfa04fe48d2121d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="73250400ef628126aea9ebff7dfa04fe48d2121d" Mention #3202 (no monomorphism restriction in GHCi) in release notes This change seems worth mentioning }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 26 22:48:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Jan 2014 22:48:10 -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.b3c5222384b45488a0ceec9ab410226e@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by rleslie): Replying to [comment:4 carter]: > any changes need to have clear meaning! > > For example, why would minBound * (-1) == minBound? > Is this an artifact of twos-complement? I can?t find anything in the Haskell 2010 Language Report that specifically mentions two?s complement representation, however ?All arithmetic is performed modulo 2?n, where `n` is the number of bits in the type.? So given a signed integer representation where `maxBound == 2^(n - 1) - 1` and `minBound == (-maxBound) - 1` as is the case in GHC, under modulo arithmetic it mathematically follows that `(-minBound) == minBound`, which is the same as `minBound * (-1) == minBound`. {{{ maxBound == 2^(n - 1) - 1 minBound == (-maxBound) - 1 == (-(2^(n - 1) - 1)) - 1 == (-2^(n - 1)) + 1 - 1 == (-2^(n - 1)) (-minBound) == (-((-maxBound) - 1)) == maxBound + 1 == 2^(n - 1) - 1 + 1 == 2^(n - 1) == 2^(n - 1) - 2^n -- (mod 2^n) == (-2^(n - 1)) == minBound }}} Note that it is already true that `minBound * (-1) == minBound` for all of the signed fixed-precision integer types in GHC. The only change I am proposing is to also have {{{minBound `quot` (-1) == minBound}}} instead of raising an exception (and likewise for `div`). Such a change is consistent with the modulo arithmetic behavior and also satisfies the class method laws of ? 6.4.2 from the Language Report: {{{ (x `quot` y)*y + (x `rem` y) == x (x `div` y)*y + (x `mod` y) == x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 02:24:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 02:24:06 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.85917c7657bdbf77f50d0d41a46de06c@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+---------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by ezyang): OK, I can't figure out what the problem is just by eyeballing the code, so I'll need to reproduce this on my machine. Can you give detailed instructions for reproduction? What patches do I need to apply? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 02:40:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 02:40:05 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.c8909b9901e9581adde71afadab014ed@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+---------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by thoughtpolice): You can set yourself up a 64bit Windows MSYS environment following this if you don't have one already: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 FWIW, me and Herbert also saw this failure. It can be triggered by a vanilla perf build, i.e. just clone and: {{{ $ ./boot; ./configure $ make }}} should trigger it while building stage2 libraries. Note that for some exceptionally strange reason, me and Herbert could not produce these results with `./validate` - you must do a regular perf build. I have not merged Kyra's patch for #7134 yet - so right now the build should still fail, no patches necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 02:41:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 02:41:27 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.5da079b27fdef7fc9fd9fa8f496d6d4d@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+---------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by thoughtpolice): I'll also mention that I do have a internet-facing Win64 build machine where you could reproduce this error from too, if you want (but a local VM would probably be easier.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 04:51:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 04:51:53 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.8481cacfe5c935110936835fb0cd9a14@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): OK, theres several things going on here, and i'm going to lay it out so i can be less confused (and hopefully i can understand your ideas better), and perhaps you can be less confused to! (though you are pointing out a real bug i think too) 1) theres currently (and unfortunately), some places in the build system where GCC is hard coded. a) historically the only C compiler GHC would support was GCC. thus historically --with-gcc was just a way of picking which gcc to use system with more than one gcc installed (I think, i could be wrong here) b) the clang support for ghc is pretty recent, and theres definitely a few corners that still need cleanup the CPP mode for Haskell code is always "traditional mode", so the flags passed to haskell CPP != the flags passed to C, though there may be some overlap -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 05:37:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 05:37:02 -0000 Subject: [GHC] #8703: Use guard pages rather than heap checks Message-ID: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> #8703: Use guard pages rather than heap checks ------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- By mmap'ing memory using MAP_ANONYMOUS (or /dev/zero) as PROT_NONE (Windows has an equivalent functionality with VirtualAlloc), it's possible to create a page that will fault when read or written to. It may be possible to remove the heap checks in the runtime, speeding up allocations, and instead expand the heap when a fault is raised. This is likely cheaper for large pages full of many small allocations than the cost of the heap checking branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 08:12:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 08:12:56 -0000 Subject: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion Message-ID: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion ------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.6.3 Keywords: fusion | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4218 | ------------------------------------+------------------------------------- randoms, randomRs could take advantage of list fusion. A commit is attached for consideration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 09:56:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 09:56:17 -0000 Subject: [GHC] #8703: Use guard pages rather than heap checks In-Reply-To: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> References: <046.cc8df1f4c44d21b3204aafaf538413fa@haskell.org> Message-ID: <061.34716b97ec2fac37b468ce64fba418f9@haskell.org> #8703: Use guard pages rather than heap checks -------------------------------------+------------------------------------ Reporter: schyler | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: This is a lot harder to do than you might imagine - the problem is not the memory protection itself, but how to handle the fault when the invalid page is accessed. This requires all kinds of platform-specific hackery. GHC's heap is constructed of linked lists of pages, so at the end of each page we have to swing the heap pointer to the next page in the list, which is often not contiguous with the previous page. Using the page fault trick is even harder when the memory must grow through non-contiguous pages, because the fault handler has to also update the current heap pointer. I'm not saying it can't be done, but it is (a) very tricky, (b) non- portable, and (c) after you've surmounted all the obstacles, it probably doesn't save that much time, if any. And because it's non-portable, you still have to keep the old way of doing things. I'm closing the ticket. But if you want to implement this and demonstrate that it is indeed a win, be my guest! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 10:43:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 10:43:47 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.7f556ddcbdf3173455ffa72801b44c29@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by simonmar): Looks great, thanks @awson! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 10:50:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 10:50:57 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.f76eceb1ddefae21932be2a7d780e0b3@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) Comment: I reported similar problem on GHC devs recently: http://www.haskell.org/pipermail/ghc-devs/2014-January/003877.html In my case failure also seems related to Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 10:53:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 10:53:53 -0000 Subject: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion In-Reply-To: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> References: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> Message-ID: <058.fa8b86cfc434b692dbc586a1a9035b85@haskell.org> #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion -------------------------------------+------------------------------------ Reporter: ion1 | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/random | Version: 7.6.3 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4218 -------------------------------------+------------------------------------ Changes (by jstolarek): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 10:58:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 10:58:05 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238702=3A_floor=2C_ceiling=2C_truncat?= =?utf-8?q?e_and_so_on=E2=80=A6_on_NaN_fail?= In-Reply-To: <046.bfb06deedd309077ba335cb50d219c1e@haskell.org> References: <046.bfb06deedd309077ba335cb50d219c1e@haskell.org> Message-ID: <061.eb07b0de097163f521c2fc72c5eeebf1@haskell.org> #8702: floor, ceiling, truncate and so on? on NaN fail -------------------------------------------------+------------------------- Reporter: skypers | Owner: Type: bug | Status: Priority: high | closed Component: libraries/base | Milestone: _|_ Resolution: duplicate | Version: 7.4.1 Operating System: Linux | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: let nan = 0 / 0 in floor nan | x86_64 (amd64) Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: 3070 -------------------------------------------------+------------------------- Changes (by jstolarek): * status: new => closed * resolution: => duplicate * related: => 3070 Comment: Duplicate of #3070. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 11:24:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 11:24:20 -0000 Subject: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion In-Reply-To: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> References: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> Message-ID: <058.36ea88b0b6694594bb7c18d78aea81f6@haskell.org> #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion -------------------------------------+------------------------------------ Reporter: ion1 | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/random | Version: 7.6.3 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4218 -------------------------------------+------------------------------------ Comment (by nomeata): Thanks for the patch, ion1. Just checking: Did you make sure that the fusion works as desired, e.g. by writing a very small example and comparing the resulting Core before and after? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 14:04:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 14:04:30 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.1b842bc054d2b40b25683a1404fb0c38@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Heh, in the previous numbers, I passed the arguments to `nofib-analyze` in the wrong order. So please swap signs. I now made sure that the `oneShot` makes it into the unfolding for `foldl`, which is a clear win. Now, relative to `master` again, I get this very nice result: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem bernouilli -0.1% +1.5% 0.14 0.14 +0.0% cryptarithm2 -0.0% -0.5% 0.01 0.01 +0.0% fem -0.0% -2.8% 0.02 0.02 +0.0% fft2 -0.1% -55.9% 0.04 0.04 +0.0% gen_regexps -0.0% -33.6% 0.00 0.00 +0.0% integrate -0.1% -59.4% 0.13 0.13 -1.0% minimax -0.0% -15.6% 0.00 0.00 +0.0% nucleic2 +0.9% +1.7% 0.05 0.05 +0.0% scs -0.0% -0.9% +1.0% +0.5% +0.0% simple -0.1% -9.4% 0.14 0.14 +0.0% x2n1 -0.1% -74.5% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min -0.2% -74.5% -3.0% -3.0% -50.0% Max +0.9% +1.7% +4.0% +3.4% +10.4% Geometric Mean -0.0% -3.7% -0.2% -0.3% -0.6% }}} So it seems to be well worth turning `foldl` into a good consumer, even if the resulting code is not perfect for complicated cases like `foldl .. .. $ concat $ ..`. The increase for `bernouilli` comes from this code line: {{{ sum $ zipWith (*) powers (tail $ tail combs) }}} where originally, because `sum` is not a good consumer, no list fusion happens and a `sum` specialized to `Integer` is used, while after the change, `sum` is fused with `zipWith`, but not further, so now we have {{{ foldr2 (\x y r eta -> r (eta + (x * y))) id powers (tail $ tail combs) 0. }}} This means that we are have elimiated one intermediate list, but we are allocating PAP ?s on each iteration, which is more expensive (three arguments instead of two!). This is verified by looking at ticky numbers. Maybe foldr2 should have been inlined here. Or we just live with it. Is this (explicit `oneShot`ness-annotations using a magic function) a path we want to go? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 17:48:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 17:48:55 -0000 Subject: [GHC] #8705: Type inference regression with local dictionaries Message-ID: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> #8705: Type inference regression with local dictionaries -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Consider this code: {{{ {-# LANGUAGE ScopedTypeVariables, TypeOperators, DataKinds, MultiParamTypeClasses, GADTs, ConstraintKinds #-} import Data.Singletons.Prelude import GHC.Exts data Dict c where Dict :: c => Dict c -- A less-than-or-equal relation among naturals class a :<=: b sLeq :: Sing n -> Sing n2 -> Dict (n :<=: n2) sLeq = undefined insert_ascending :: forall n lst n1. (lst ~ '[n1]) => Proxy n1 -> Sing n -> SList lst -> Dict (n :<=: n1) insert_ascending _ n lst = case lst of -- If lst has one element... SCons h _ -> case sLeq n h of -- then check if n is <= h Dict -> Dict -- if so, we're done }}} (adapted from [https://github.com/goldfirere/singletons/blob/master/Test/InsertionSortImp.hs this file]) GHC 7.6.3 compiles without incident. When I run HEAD (with `-fprint- explicit-kinds`), I get {{{ Ins.hs:25:17: Could not deduce (n :<=: n1) arising from a use of ?Dict? from the context ((~) [*] lst ((':) * n1 ('[] *))) bound by the type signature for insert_ascending :: (~) [*] lst ((':) * n1 ('[] *)) => Proxy * n1 -> Sing * n -> SList * lst -> Dict (n :<=: n1) at Ins.hs:(20,21)-(21,70) or from ((~) [*] lst ((':) * n0 n2)) bound by a pattern with constructor SCons :: forall (a0 :: BOX) (z0 :: [a0]) (n0 :: a0) (n1 :: [a0]). (~) [a0] z0 ((':) a0 n0 n1) => Sing a0 n0 -> Sing [a0] n1 -> Sing [a0] z0, in a case alternative at Ins.hs:24:7-15 or from (n :<=: n0) bound by a pattern with constructor Dict :: forall (c :: Constraint). (c) => Dict c, in a case alternative at Ins.hs:25:9-12 Possible fix: add (n :<=: n1) to the context of the data constructor ?Dict? or the data constructor ?SCons? or the type signature for insert_ascending :: (~) [*] lst ((':) * n1 ('[] *)) => Proxy * n1 -> Sing * n -> SList * lst -> Dict (n :<=: n1) In the expression: Dict In a case alternative: Dict -> Dict In the expression: case sLeq n h of { Dict -> Dict } }}} If you stare at the type error long enough, you will see that GHC should be able to type-check this. The test case requires singletons-0.9.x, but is already much reduced. Interestingly, if all the "givens" are put in the top-level type signature, GHC does its job well. It seems that the act of unpacking the dictionaries is causing the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 17:53:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 17:53:37 -0000 Subject: [GHC] #8706: Kind operators not parsed Message-ID: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> #8706: Kind operators not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Take the following module: {{{ {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies #-} data a + b = Inl a | Inr b type family Foo :: Bool + Bool }}} HEAD produces {{{ /Users/rae/temp/Bug.hs:5:25: parse error on input ?+? }}} It seems that type operators promoted to kinds are not parsed correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 17:54:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 17:54:30 -0000 Subject: [GHC] #8705: Type inference regression with local dictionaries In-Reply-To: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> References: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> Message-ID: <062.fa89828b76044eb83d8b6f608b33ebdb@haskell.org> #8705: Type inference regression with local dictionaries --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 18:03:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 18:03:30 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition Message-ID: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> #8707: Kind inference fails in data instance definition ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following shenanigans: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, GADTs #-} data family SingDF (a :: (k, k2 -> *)) data Ctor :: k -> * data instance SingDF (a :: (Bool, Bool -> *)) where SFalse :: SingDF '(False, Ctor) }}} HEAD reports (with `-fprint-explicit-kinds`) {{{ Data constructor ?SFalse? returns type ?SingDF Bool k '('False, Ctor k)? instead of an instance of its parent type ?SingDF Bool Bool a? In the definition of data constructor ?SFalse? In the data instance declaration for ?SingDF? }}} I see two problems here: 1) Kind inference should fix the problem. If I add a kind annotation to `Ctor`, the code works. GHC should be able to infer this kind annotation for me. 2) The error message is not particularly helpful. GHC 7.6.3 had a more verbose, but more helpful message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 18:07:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 18:07:52 -0000 Subject: [GHC] #8708: Kind annotation in tuple not parsed Message-ID: <047.7299eca00fb25a2e788e2c82e2894717@haskell.org> #8708: Kind annotation in tuple not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Consider this: {{{ {-# LANGUAGE KindSignatures #-} foo :: (Int, Int :: *) foo = undefined }}} HEAD reports {{{ /Users/rae/temp/Bug.hs:5:18: parse error on input ?::? }}} Changing the line to {{{ foo :: (Int, (Int :: *)) }}} fixes the problem. Note the extra parentheses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 18:45:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 18:45:00 -0000 Subject: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion In-Reply-To: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> References: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> Message-ID: <058.4857283bf7c67556ed87dd13f573568b@haskell.org> #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion -------------------------------------+------------------------------------ Reporter: ion1 | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/random | Version: 7.6.3 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4218 -------------------------------------+------------------------------------ Comment (by ion1): Yes, I tested with {{{ main = do { gen <- newStdGen; mapM_ print (randoms gen) } }}} which resulted in the list data structure being optimized away entirely (along with the pattern match for the empty case in `mapM_`). I got around to doing some benchmarking after posting the patch and I seem unable to come up with code for which `randoms` fusion makes a difference in performance, though. Unless someone else thinks of something I didn?t, this might not be worth it. The `seq` fix for part of #4218 can be done independently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 18:48:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 18:48:37 -0000 Subject: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion In-Reply-To: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> References: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> Message-ID: <058.101cb880f5abe7be42fa28550c431dbd@haskell.org> #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion -------------------------------------+------------------------------------ Reporter: ion1 | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/random | Version: 7.6.3 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4218 -------------------------------------+------------------------------------ Comment (by nomeata): Thanks. From my POV it is worth adding even if you can?t measure a performance gain; it is still good to know that nice code is being generated. But of course it is up to Ryan Newton (random maintainer) to decide this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 18:53:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 18:53:32 -0000 Subject: [GHC] #8709: `make 1` does not work (well) Message-ID: <047.74dec05c27dff19fcb1196415db32998@haskell.org> #8709: `make 1` does not work (well) ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Say I do a `sync-all pull` and then fix a bunch of merge errors. The changes mean that I need to recompile the stage-1 compiler. So, I dutifully `make distclean` and start rebuilding. I then find a bunch of compiler errors in my edited code. Now, I'd like to start the fix error/recompile loop. BUT, when I do `make 1` in the `compiler/` directory, I get errors: {{{ rae:13:49:29 ~/Documents/ghc/compiler> make 1 make -C .. stage=1 all_ghc_stage1 compiler_dist_NO_BUILD_DEPS=YES compiler_dist-boot_NO_BUILD_DEPS=YES compiler_dist- install_NO_BUILD_DEPS=YES NO_GENERATED_MAKEFILE_RULES=YES OMIT_PHASE_0=YES OMIT_PHASE_1=YES compiler_stage1_NO_BUILD_DEPS=YES compiler_stage2_NO_BUILD_DEPS=YES compiler_stage3_NO_BUILD_DEPS=YES ghc_stage1_NO_BUILD_DEPS=YES ghc_stage2_NO_BUILD_DEPS=YES ghc_stage3_NO_BUILD_DEPS=YES ONLY_DEPS_FOR="compiler_stage1 ghc_stage1" ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all_ghc_stage1 libraries/old-time/ghc.mk:5: libraries/old-time/dist-install/package- data.mk: No such file or directory libraries/haskell98/ghc.mk:5: libraries/haskell98/dist-install/package- data.mk: No such file or directory libraries/haskell2010/ghc.mk:5: libraries/haskell2010/dist-install /package-data.mk: No such file or directory libraries/random/ghc.mk:5: libraries/random/dist-install/package-data.mk: No such file or directory libraries/primitive/ghc.mk:5: libraries/primitive/dist-install/package- data.mk: No such file or directory libraries/vector/ghc.mk:5: libraries/vector/dist-install/package-data.mk: No such file or directory libraries/dph/dph-base/ghc.mk:5: libraries/dph/dph-base/dist-install /package-data.mk: No such file or directory libraries/dph/dph-prim-interface/ghc.mk:5: libraries/dph/dph-prim- interface/dist-install/package-data.mk: No such file or directory libraries/dph/dph-prim-seq/ghc.mk:5: libraries/dph/dph-prim-seq/dist- install/package-data.mk: No such file or directory libraries/dph/dph-prim-par/ghc.mk:5: libraries/dph/dph-prim-par/dist- install/package-data.mk: No such file or directory libraries/dph/dph-lifted-base/ghc.mk:5: libraries/dph/dph-lifted-base /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-boxed/ghc.mk:5: libraries/dph/dph-lifted-boxed /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-copy/ghc.mk:5: libraries/dph/dph-lifted-copy /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-vseg/ghc.mk:5: libraries/dph/dph-lifted-vseg /dist-install/package-data.mk: No such file or directory libraries/ghc-prim/ghc.mk:4: libraries/ghc-prim/dist-install/package- data.mk: No such file or directory libraries/integer-gmp/ghc.mk:4: libraries/integer-gmp/dist-install /package-data.mk: No such file or directory libraries/base/ghc.mk:4: libraries/base/dist-install/package-data.mk: No such file or directory libraries/filepath/ghc.mk:4: libraries/filepath/dist-install/package- data.mk: No such file or directory libraries/array/ghc.mk:4: libraries/array/dist-install/package-data.mk: No such file or directory libraries/deepseq/ghc.mk:4: libraries/deepseq/dist-install/package- data.mk: No such file or directory libraries/bytestring/ghc.mk:4: libraries/bytestring/dist-install/package- data.mk: No such file or directory libraries/containers/ghc.mk:4: libraries/containers/dist-install/package- data.mk: No such file or directory libraries/old-locale/ghc.mk:4: libraries/old-locale/dist-install/package- data.mk: No such file or directory libraries/time/ghc.mk:4: libraries/time/dist-install/package-data.mk: No such file or directory libraries/unix/ghc.mk:4: libraries/unix/dist-install/package-data.mk: No such file or directory libraries/directory/ghc.mk:4: libraries/directory/dist-install/package- data.mk: No such file or directory libraries/process/ghc.mk:4: libraries/process/dist-install/package- data.mk: No such file or directory libraries/hpc/ghc.mk:4: libraries/hpc/dist-install/package-data.mk: No such file or directory libraries/pretty/ghc.mk:4: libraries/pretty/dist-install/package-data.mk: No such file or directory libraries/template-haskell/ghc.mk:4: libraries/template-haskell/dist- install/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:4: libraries/Cabal/Cabal/dist-install /package-data.mk: No such file or directory libraries/binary/ghc.mk:4: libraries/binary/dist-install/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:4: libraries/bin-package-db/dist-install /package-data.mk: No such file or directory libraries/hoopl/ghc.mk:4: libraries/hoopl/dist-install/package-data.mk: No such file or directory libraries/transformers/ghc.mk:4: libraries/transformers/dist-install /package-data.mk: No such file or directory libraries/xhtml/ghc.mk:4: libraries/xhtml/dist-install/package-data.mk: No such file or directory libraries/terminfo/ghc.mk:4: libraries/terminfo/dist-install/package- data.mk: No such file or directory libraries/haskeline/ghc.mk:4: libraries/haskeline/dist-install/package- data.mk: No such file or directory libraries/integer-gmp/gmp/ghc.mk:49: libraries/integer-gmp/gmp/config.mk: No such file or directory utils/hsc2hs/ghc.mk:16: utils/hsc2hs/dist-install/package-data.mk: No such file or directory utils/ghc-pkg/ghc.mk:66: utils/ghc-pkg/dist-install/package-data.mk: No such file or directory utils/dll-split/ghc.mk:18: utils/dll-split/dist-install/package-data.mk: No such file or directory utils/ghc-pwd/ghc.mk:8: utils/ghc-pwd/dist-install/package-data.mk: No such file or directory utils/ghc-cabal/ghc.mk:67: utils/ghc-cabal/dist-install/package-data.mk: No such file or directory utils/hpc/ghc.mk:18: utils/hpc/dist-install/package-data.mk: No such file or directory utils/runghc/ghc.mk:28: utils/runghc/dist-install/package-data.mk: No such file or directory utils/mkUserGuidePart/ghc.mk:18: utils/mkUserGuidePart/dist/package- data.mk: No such file or directory utils/compare_sizes/ghc.mk:8: utils/compare_sizes/dist-install/package- data.mk: No such file or directory make[2]: *** No rule to make target `libraries/integer-gmp/gmp/config.mk'. Stop. make[1]: *** [all_ghc_stage1] Error 2 make: *** [1] Error 2 }}} Using `make stage=1` works fine, but computing the dependencies each time is annoying. In past experience, I've seen that, once the stage-1 compiler builds to completion at least once, `make 1` works just fine -- it just fails after a `clean`. I don't recall having this problem with `make 2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 18:57:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 18:57:10 -0000 Subject: [GHC] #8709: `make 1` does not work (well) In-Reply-To: <047.74dec05c27dff19fcb1196415db32998@haskell.org> References: <047.74dec05c27dff19fcb1196415db32998@haskell.org> Message-ID: <062.ff7f6f8c7561a4437c2f83431a43175f@haskell.org> #8709: `make 1` does not work (well) -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): On a whim, I went to `libraries/integer-gmp` and said `./configure`. Now `make 1` is working! Yay! But, this shouldn't require my intervention... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 21:01:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 21:01:11 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.0982c15bb121bf061c9a0a18e5219aa0@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by MikeIzbicki): We could have 1.3 just be sugar for 13/10, so both notations would be acceptable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 21:28:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 21:28:19 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.abad07622a8ca793a2c0bdeaf714fa94@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): @mike, you could actually use template haskell to write generate type rationals pretty easily. It should also work with 7.6 and earlier ones, though there may be a few corner cases in older ghcs something like $(makeRatType 7/8) with makeRatType :: Rational -> Q Type being suitably defined. Have you tried out doing that as a near term solution? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 22:19:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 22:19:24 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.e619bc1bc4885f696d3bdf676c5943bc@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by MikeIzbicki): @carter I'm not sure what you're suggesting. The following code (combined with the code above) does exactly what I want: {{{ data Blah (num::Frac) = Blah f :: Blah num -> Rational f = ... g = f (Blah::Blah (13/10)) }}} It would just be nice to be able to write {{{ g = f (Blah::Blah 1.3) }}} instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 23:17:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 23:17:13 -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.1f85eed52554914c8499f65a76bef0ee@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------ Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 5144 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ntc2): I've often wished that `_` in expressions was a shorthand for `undefined`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 23:26:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 23:26:50 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.c0a7005dc52f15df2aaa9032f0c3570d@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"8f8bd88ce654828fef44378c3a4732d6941b9596/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f8bd88ce654828fef44378c3a4732d6941b9596" Fix the Win64 RTS linker & disable .ctors This fixes #7134 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 27 23:43:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Jan 2014 23:43:59 -0000 Subject: [GHC] #8453: segfault/assertion failure with multi-threaded profiling In-Reply-To: <043.88830003a4aab2e0f30d4506087b121b@haskell.org> References: <043.88830003a4aab2e0f30d4506087b121b@haskell.org> Message-ID: <058.96a89a4ab114412809266a7a4901d76d@haskell.org> #8453: segfault/assertion failure with multi-threaded profiling ----------------------------------+---------------------------------- Reporter: akio | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: 8402 Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: I left this open to track adding the bug to the testsuite, but unfortunately there's no real easy way to do this, it seems. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 00:09:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 00:09:47 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.9600cc746205799325683c57aa22fdd8@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T7478 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: simonmar (added) * version: 7.6.1 => 7.7 * milestone: 7.6.2 => 7.8.1 Comment: On my 32bit linux machine (but not 64bit), I see the following test failure in a regular `./validate` run. It fails rather unhelpfully by just saying "phase 'Linker' failed (exitcode = 1)", but after patching the test to use `-v3` verbosity, I get this output: {{{ ... wired-in package ghc-prim mapped to ghc-prim-0.3.1.0-inplace wired-in package integer-gmp mapped to integer-gmp-0.5.1.0-inplace wired-in package base mapped to base-4.7.0.0-inplace wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-inplace wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *C.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2014-01-21 15:09:29.865159778 UTC ms_mod = main:Main, ms_textual_imps = [import (implicit) Prelude] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file C.hs *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 7, types: 7, coercions: 0} *** Simplifier: Result size of Simplifier = {terms: 7, types: 7, coercions: 0} *** Tidy Core: Result size of Tidy Core = {terms: 7, types: 7, coercions: 0} writeBinIface: 1 Names writeBinIface: 12 dict entries *** CorePrep: Result size of CorePrep = {terms: 7, types: 7, coercions: 0} *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** Assembler: /usr/bin/gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -x assembler-with-cpp -c /tmp/ghc7616_0/ghc7616_7.s -o C.o Upsweep completely successful. *** Deleting temp files: Deleting: /tmp/ghc7616_0/ghc7616_8.c /tmp/ghc7616_0/ghc7616_7.s /tmp/ghc7616_0/ghc7616_6.s Warning: deleting non-existent /tmp/ghc7616_0/ghc7616_8.c Warning: deleting non-existent /tmp/ghc7616_0/ghc7616_6.s link: linkables are ... LinkableM (2014-01-26 02:04:53.320777465 UTC) main:Main [DotO C.o] *** C Compiler: /usr/bin/gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc7616_0/ghc7616_9.c -o /tmp/ghc7616_0/ghc7616_10.o -I/home/a/ghc/rts/dist/build -I/home/a/ghc/includes -I/home/a/ghc/includes /dist-derivedconstants/header *** C Compiler: /usr/bin/gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc7616_0/ghc7616_11.s -o /tmp/ghc7616_0/ghc7616_12.o -I/home/a/ghc/rts/dist/build -I/home/a/ghc/includes -I/home/a/ghc/includes /dist-derivedconstants/header *** Linker: /usr/bin/gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -o A C.o -L/home/a/ghc/libraries/base/dist-install/build -Wl,-rpath-link -Wl,/home/a/ghc/libraries/base/dist-install/build -Wl,-rpath -Wl,/home/a/ghc/libraries/base/dist-install/build -L/home/a/ghc/libraries /integer-gmp/dist-install/build -Wl,-rpath-link -Wl,/home/a/ghc/libraries /integer-gmp/dist-install/build -Wl,-rpath -Wl,/home/a/ghc/libraries /integer-gmp/dist-install/build -L/home/a/ghc/libraries/ghc-prim/dist- install/build -Wl,-rpath-link -Wl,/home/a/ghc/libraries/ghc-prim/dist- install/build -Wl,-rpath -Wl,/home/a/ghc/libraries/ghc-prim/dist- install/build -L/home/a/ghc/rts/dist/build -Wl,-rpath-link -Wl,/home/a/ghc/rts/dist/build -Wl,-rpath -Wl,/home/a/ghc/rts/dist/build /tmp/ghc7616_0/ghc7616_10.o /tmp/ghc7616_0/ghc7616_12.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlers_closure -lHSbase-4.7.0.0-ghc7.7.20140122 -lHSinteger-gmp-0.5.1.0-ghc7.7.20140122 -lHSghc-prim-0.3.1.0-ghc7.7.20140122 -lHSrts-ghc7.7.20140122 -lffi -lgmp -lm -lrt -ldl '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads /usr/bin/ld: dynamic variable `base_GHCziBase_zdfMonadIO_closure' is zero size /usr/bin/ld: dynamic variable `ghczmprim_GHCziTuple_Z0T_closure' is zero size /usr/bin/ld: dynamic variable `base_GHCziTopHandler_runMainIO_closure' is zero size /usr/bin/ld: C.o(.text+0x3b): unresolvable R_386_32 relocation against symbol `base_GHCziBase_zdfMonadIO_closure' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status T7478: T7478: phase `Linker' failed (exitcode = 1) make[1]: *** [T7478] Error 1 }}} I haven't taken the time to fully track this down yet unfortunately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 00:50:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 00:50:45 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced Message-ID: <047.1f227e0dac37dd7309646386f280164b@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: bug | Milestone: Priority: low | Version: 7.7 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Consider {{{ {-# OPTIONS_GHC -fwarn-overlapping-patterns #-} len [] = 0 len (_:t) = 1 + len t len _ = error "urk" }}} GHC reports the problem with this definition at the first line of it. I think it would be more helpful to have it at the last line, which is the pattern that will never match. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 04:01:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 04:01:32 -0000 Subject: [GHC] #8647: Reduce allocations in `integer-gmp` In-Reply-To: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> References: <042.0fee71df056a1a1576fef5363fc288c3@haskell.org> Message-ID: <057.0c5a23db99a52e0bb37d98ad96b51c26@haskell.org> #8647: Reduce allocations in `integer-gmp` --------------------------------------------+------------------------------ Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: integer- Operating System: Unknown/Multiple | gmp Type of failure: Runtime performance bug | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #8638 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: patch => new Comment: This work is basically completed for 7.8, but Herbert will do more. At the moment this doesn't need to be in patch status. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 04:37:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 04:37:34 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.a9ad4d999ff3129a7d9a3da7bc1ae03c@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): oh, i think that theres support for that in the parser already... have you tried in HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 04:52:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 04:52:18 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.2e027db2ca149a9aecb6103b529fd844@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by MikeIzbicki): I wasn't aware of any GHC support for type level fractions. Any idea what the name of the kind is so I can try it out? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 05:04:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 05:04:54 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.8e7416730796e326955dd647097eca15@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): woops, mispoke, i'm a bit exhausted. There is no such support :) do you have a strawman data model for a type level rationals? Eg using one of the preexisting libraries for type level ints, building up an associated rational set of operations and model types? Also on the template haskell front, I meant that via template haskell you could do a function that lets you write rationals in decimal notation using template haskell, because decimal numbers can be parsed as rationals. eg in $(makeRatType 7.3), 7.3 would be turned into rational value. This works at the value level, ableit at template haskell time so you can construct the type -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 08:37:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 08:37:25 -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.4f81a3a0cedb4bcb473785d2dec6fc19@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by hvr): Fwiw as a precedent, the following C99 program when compiled with gcc or clang, and executed on Linux results in a runtime exception as well: {{{#!c #include #include int main(int argc, char *argv[]) { volatile int32_t a = INT32_MIN; volatile int32_t b = -1; volatile int32_t c = a / b; printf("%" PRId32 "\n", c); return 0; } }}} Given that `quot`/`div` is already a partial function due to div-by-zero, and {{{minBound `quot` -1}}} being the only special case (beside div-by- zero) for (`quot`/`div`) which leads to a result outside the `[minBound..maxBound]` range, so I'd rather have this exception thrown than to have a program which didn't take into account this non-obvious overflow silently misbehaving due to a flipped sign (as you pointed out yourself if I understood you correctly, but then dismissed it as not being worth an exception). PS: I believe one may as well argue (as an academic exercise) in a parallel way, that `quotRem` by 0 could be assigned a value that satisfies the laws from ? 6.4.2 as well, thus making it a total function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 09:39:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 09:39:29 -0000 Subject: [GHC] #4466: Add extension for type application In-Reply-To: <044.fde123cc43374cdc1e81854ca78c4770@haskell.org> References: <044.fde123cc43374cdc1e81854ca78c4770@haskell.org> Message-ID: <059.e7c77dccf021be1e0d9ac3c79217510a@haskell.org> #4466: Add extension for type application -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 09:40:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 09:40:02 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.67e37171985485f108722533f63f1140@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (Type | Version: 7.0.3 checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Project (more Type of failure: GHC rejects | than a week) valid program | Blocked By: 1897 Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 10:35:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 10:35:13 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.08014c3370b755b3e195038656a0564e@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T7478 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I expect there's a mismatch between modules compiled with `-dynamic` and without, or something like that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 11:10:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 11:10:21 -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.a2406dc1f65bf6c11683bae2706b0ee2@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by rleslie): Replying to [comment:6 hvr]: > Fwiw as a precedent, the following C99 program when compiled with gcc or clang, and executed on Linux results in a runtime exception as well: > > {{{#!c > #include > #include > > int main(int argc, char *argv[]) > { > volatile int32_t a = INT32_MIN; > volatile int32_t b = -1; > volatile int32_t c = a / b; > printf("%" PRId32 "\n", c); > return 0; > } > }}} In C, the behavior of signed integer operations that overflow is undefined, so this is not unexpected. In Haskell, we have Data.Int which declares that signed fixed-precision integer arithmetic operations are performed modulo 2!^n, and thus do not overflow. Except {{{minBound `quot` (-1)}}} violates this rule. > Given that `quot`/`div` is already a partial function due to div-by- zero, and {{{minBound `quot` -1}}} being the only special case (beside div-by-zero) for (`quot`/`div`) which leads to a result outside the `[minBound..maxBound]` range, so I'd rather have this exception thrown than to have a program which didn't take into account this non-obvious overflow silently misbehaving due to a flipped sign (as you pointed out yourself if I understood you correctly, but then dismissed it as not being worth an exception). The same argument could be made for many other arithmetic operations, like `minBound * (-1)`, as well as `minBound - 1`, `maxBound + 1`, etc. I don't see any reason to have a special case for {{{minBound `quot` (-1)}}}. It happens that the only reason I discovered this behavior and have reported it as a bug is that it unexpectedly caused a program to abort rather than return the (expected) modulo arithmetic result. So a non- obvious and unexpected exception can equally cause a program to misbehave. This can be especially devastating in a server application. A program that is sensitive to overflow conditions probably ought not be using fixed-precision integers in the first place; `Integer` would be a better choice. But despite what you or I might prefer, the fact remains that modulo arithmetic is the documented behavior for signed fixed-precision integers, so I still tend to view the exception thrown by {{{minBound `quot` (-1)}}} as a bug. > PS: I believe one may as well argue (as an academic exercise) in a parallel way, that `quotRem` by 0 could be assigned a value that satisfies the laws from ? 6.4.2 as well, thus making it a total function. While that might be an interesting exercise, the laws I quoted only apply ?if `y` is non-zero?. So I argue the laws ''demand'' satisfaction when `y` is `(-1)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 13:54:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 13:54:43 -0000 Subject: [GHC] #8711: StaticValues language extension Message-ID: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> #8711: StaticValues language extension -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- See [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-January/024571.html this thread]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 13:57:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 13:57:57 -0000 Subject: [GHC] #8711: StaticValues language extension In-Reply-To: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> References: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> Message-ID: <071.1bad6b1257b6089d7232586d034868be@haskell.org> #8711: StaticValues language extension -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: new Type: feature request | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Project (more Type of failure: None/Unknown | than a week) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * owner: => facundo.dominguez * difficulty: Unknown => Project (more than a week) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 14:27:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 14:27:09 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.bb02324546e1a4599b3d5f7845ec2864@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"28b031c506122e28e0230a562a4f6fd3d0256d0c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="28b031c506122e28e0230a562a4f6fd3d0256d0c" Refactor GCTDecl.h, and mitigate #7602 a bit This basically cleans a lot of GCTDecl up - I found it quite hard to read and a bit confusing. The changes are mostly cosmetic: better delineation between the alternative cases and light touchups, and tries to make every branch as consistent as possible. However, this patch does have one significant effect: it will ensure that any LLVM-based compilers will use __thread if they support it. Before, they would simply always use pthread_getspecific and pthread_setspecific, which are almost surely even *more* inefficient. The details are a bit too long and boring to go into here; see #7602. After talking with Simon, we decided to play it safe - __thread can at least be optimized by future clang releases even further on OS X if they choose, and it's safer until we can investigate the pthread implementation further on Mavericks. For Linux, the story isn't so bleak if you use Clang (for whatever reason) - Linux directly writes to `%fs` for __thread slots (while OS X will perform a load followed by an indirect call.) So it should still be fairly competitive, speed-wise. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 14:27:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 14:27:09 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.7ba143d2eb241e78a26f6f7307d5fb38@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Austin Seipp ): In [changeset:"f7be53ac9dac85b83e7fe5ecede01b98a572ba48/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f7be53ac9dac85b83e7fe5ecede01b98a572ba48" Fix inplace dynamic linking on OS X (#8266) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 14:28:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 14:28:41 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.a1d846d0f87d4a17745c61c3d51180e6@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by thoughtpolice): Thank you Christiaan. The GHC patch is merged and it seems to work well. I have not merged the Cabal patch, as that's more under the authority of Duncan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 14:32:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 14:32:53 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.d8400539cd00ad0af566fd9567be6476@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: fixed | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * blockedby: 3658 => Comment: Thank you Kyrill! Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 14:43:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 14:43:35 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.7a76b17e9e9a5893831feb8045ef663a@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by Austin Seipp ): In [changeset:"25821cc9793c15e9860b3dcddf50aebf0eb718f7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="25821cc9793c15e9860b3dcddf50aebf0eb718f7" Win64 linker: fix loading foreign imports (#2283) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 14:44:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 14:44:59 -0000 Subject: [GHC] #8711: StaticValues language extension In-Reply-To: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> References: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> Message-ID: <071.93f24c6a57dddb0122e9392ff3f2060b@haskell.org> #8711: StaticValues language extension -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: new Type: feature request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Project (more Type of failure: None/Unknown | than a week) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * version: 7.6.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 14:49:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 14:49:19 -0000 Subject: [GHC] #8681: Don't disable dynamic linking for LLVM flavours In-Reply-To: <046.7d00c22f21a52b42f6545d7d4a2e8357@haskell.org> References: <046.7d00c22f21a52b42f6545d7d4a2e8357@haskell.org> Message-ID: <061.be4f26cee0e44d11c9ad928f7a878a9e@haskell.org> #8681: Don't disable dynamic linking for LLVM flavours -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks Ben! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 15:00:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 15:00:50 -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.f66abcca6ad3d0083e4096805ac07ac0@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by ekmett): One could argue that it is the status quo making the special case out of {{{y = -1}}}. But, without prejudging the answer, let's look at what the class is attempting to model. It has taken me a few times to get this to come out to the correct answer here, so I'm going to be very very pedantic. =) The current class laws are insufficient to properly model the notion of a Euclidean domain. To be a proper Euclidean domain {{{(x `quot` y)*y + (x `rem` y) == x}}} isn't the only law. The standard statement of the Euclidean domain axiom is that there exists a Euclidean gauge function `f :: r -> Nat` such that if `a` and `b` are in the domain and `b /= 0`, then there are `q` and `r` such that `a = bq + r` and either `r = 0` or `f(r) < f(b)`. Both the (`div`,`mod`) pair and the (`quot`, `rem`) pair (more or less) satisfy these conditions with `f = abs`, so whenever I say `f` in the sequel, you can just think `abs`, but I'm using it to keep my head straight. It'll only matter that I'm making this distinction at the very end. The assumption that `b` is non-zero rules out Herbert's case directly, but if you remove the side-condition that `b /= 0`, it is ruled out by the conditions on `r`. e.g. If `(q,r) = quotRem x 0` then {{{x = q*0 + r}}} by the simplified definition, but then `x = r`, so `f(x) < f(r)` fails to hold and the `r == 0` case only saves you when you divide 0 by 0. These rules kind of rule out the tongue-in-cheek extension of `quotRem` to cover `0` in one sense. In another, however, the definition doesn't say what happens when `b == 0`. For simplicity I'd like to carry on with the convention that either `r = 0` or `f(r) < f(y)` holds regardless and continue to treat `b == 0` as an error it makes sense both by convention and by the underlying mathematics. With that as a warmup, let's get back to {{{(x `quot` -1)}}} in {{{Z mod 2^n}}}. {{{ (minBound `quot` -1)* (-1) + (minBound `rem` y) minBound + (minBound `rem` y) = minBound }}} says that `q = minBound` and `r = 0` would be the required answers. The only issue here is that stating `f = abs` doesn't work as we have the wart forced on us by the asymmetry of 2s complement arithmetic {{{ >>> abs (minBound :: Int) -9223372036854775808 }}} on the other hand, we've been using `abs` as an approximation of an injection into the natural numbers `f`, which does not have this limitation! Basically this requires `f = abs . toInteger`, then the side condition on `f` holds. So all of this indicates to me that the extension to support {{{minBound `quot` -1 = minBound}}} is correct and _is_ consistent with the definition of a Euclidean domain independent of 2s complement concerns. This frankly seems like a slam dunk to me and I'm in favor of the change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 15:02:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 15:02:23 -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.04e66aa5266888334ab39103e0911994@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by ekmett): * cc: ekmett@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 15:06:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 15:06:19 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.115a8cc217b2bc3ac2313bd7b6ffa9fb@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I have come up with a stand-alone analysis that tries to find out the ?caller arity? of a function. Quite a bit like the usage demand, but different from the demand analyser in a few aspects: It does not bother about the demand put on function arguments by a function (so much less fixed-pointing due to that), and it currently looks only for tail-calls (or almost-tail-calls; some post-processing of return values a after the ?tail call? is ok, as long as it does not do any relevant calls). It is an analysis phase that puts the result in the IdInfo, and the simplifier will eta-expand functions where the ?caller arity? is higher than the manifest arity. It has zero effect on the current code base. If I implement `foldl` via `foldr` (but ''without'' the use of `oneShot`), I get essentially the same as the result as without the analysis, but with the explicit `oneShot`: {{{ Min -0.2% -74.5% -3.0% -3.0% -50.0% Max +0.9% +1.8% +2.5% +2.5% +14.8% Geometric Mean -0.0% -3.7% -0.3% -0.3% -0.5% }}} It still does not help with `bernoulli`, and probably nothing will: Implementing `foldl` as `foldr` will always yield bad code if list fusion does not work all the way and the `build` (or in this case, `build2`) is not completely gone. But if list fusion works, the results can be very good The `oneShot` change is much simpler, has little risk of introducing bugs and does not increase compilation times. The ?caller arity? pass, OTOH, may optimise other code as well (but at least nofib does not seem to contain much such code), and can likely be made more precise. But the conclusion is that `foldl` can be made a good consumer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 16:28:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 16:28:58 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.ec461149e5dc5eb51cb6ef1643348465@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): JFTR: Simon discussed this with me and encouraged me to pursue the analysis (but don?t merge it before 7.8 has been branched off). But even more so I?d like to record a few things about the `oneShot` approach: * Would also be nice, and can still be revived if we find cases where the analysis fails. * It should always be inlined when passed two arguments. * Could be made to inline very very late, but then it should have a strictness signature. * In that case, one would have to make sure it does not get in the way of CPR or other analysis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 16:38:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 16:38:45 -0000 Subject: [GHC] #8107: need types to express constant argument for primop correctness In-Reply-To: <045.7a159c5513dff4683fe6798d6101cb07@haskell.org> References: <045.7a159c5513dff4683fe6798d6101cb07@haskell.org> Message-ID: <060.743627299f91167aa84808bcba1fd88a@haskell.org> #8107: need types to express constant argument for primop correctness -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8252 | Related Tickets: #8131 -------------------------------------+------------------------------------ Changes (by carter): * owner: => carter -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 16:45:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 16:45:05 -0000 Subject: [GHC] #8285: unexpected behavior with encodeFloat on large inputs In-Reply-To: <045.f7eaecd94e96f3fd291d7a1c2d15ebef@haskell.org> References: <045.f7eaecd94e96f3fd291d7a1c2d15ebef@haskell.org> Message-ID: <060.065ce32af06653f0a07807f5bd994545@haskell.org> #8285: unexpected behavior with encodeFloat on large inputs ------------------------------------------------+-------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by carter): This seems like its worth fixing, if theres a reasonable solution. My understanding is the the current code just punts on handling these corner cases properly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 18:00:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 18:00:10 -0000 Subject: [GHC] #8711: StaticValues language extension In-Reply-To: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> References: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> Message-ID: <071.f86648404635c17478a90f72b7394ce3@haskell.org> #8711: StaticValues language extension -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: new Type: feature request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Project (more Type of failure: None/Unknown | than a week) Test Case: | Blocked By: Blocking: | Related Tickets: #8107 -------------------------------------+------------------------------------- Changes (by carter): * related: => #8107 Comment: This is somewhat related to my own static data work in-progress. I think that with GHC 7.8, it'd be possible (and valuable) to prototype this proposal as a userland library. Theres a LOT of corner cases that would need to be very very precisely / throughly handled for this to be worth supporting in ghc proper, and I very strongly suspect that with the right (seemingly unrelated) extensions, it'd actually be quite feasible to make this feature request a user land library. namely: making sure that GHC API tooling for supporting dynamic loading and unloading of code works for this use case! see the ObjLink api http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html and http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.html works or not. Mind you, I'd recommend testing out the GHC HEAD / 7.8 variant of the api, because there were a few known issues in 7.6. Theres also some ideas for doing idris style EDSL support (which would kinda look like doing statically typed quasiquoters for haskell expressions) that would support this and a few other use cases quite nicely I think. I understand and appreciate the end goal. I think that the current GHC APIs are enough to support this or something very close to it as a user land library. I'd also say that it'd be instructive to have some very very concrete examples illustrating what (if anything) can't be done currently from a userland perspective. I know for a fact that a number of organizations are using the Obj Loading facilities, or abstractions on top thereof, such as the hint lib http://hackage.haskell.org/package/hint to provide such "computation serialization". These organizations include, but are not limited to Facebook and Soostone. If you have some examples that aren't viable with such an approach, and/or would be much much nicer in your proposed scheme, please share! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 18:08:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 18:08:19 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.bc08195c743be144d61ee745372e816d@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"4a8ffcf55c897851b534c700951a0b5bdd43eb97/base"]: {{{ #!CommitTicketReference repository="base" revision="4a8ffcf55c897851b534c700951a0b5bdd43eb97" go-ify foldr2 This helps with the changes in #7994, but might also generally be a good idea (ignore the runtime): -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem fft2 -0.1% -1.5% 0.07 0.07 +0.0% fibheaps +0.0% -17.2% 0.03 0.03 +0.0% fluid +0.5% -0.7% 0.01 0.01 +0.0% integrate +0.0% -0.9% 0.16 0.16 +0.0% rewrite +0.0% -1.1% 0.02 0.02 +0.0% -------------------------------------------------------------------------------- Min -0.1% -17.2% -1.6% +0.0% +0.0% Max +0.5% +0.0% +107.7% +106.2% +11.3% Geometric Mean +0.0% -0.2% +23.7% +23.9% +0.1% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 20:11:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 20:11:30 -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.cbac210789ae699eaaca84f31616f618@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Changes (by hvr): * related: => #1042 Comment: Fyi, while preparing a patch I found #1042 which introduced the exception in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 20:12:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 20:12:15 -0000 Subject: [GHC] #1042: Floating point exception In-Reply-To: <043.a5be1d72d3d949715655e3ba90022338@haskell.org> References: <043.a5be1d72d3d949715655e3ba90022338@haskell.org> Message-ID: <058.c7191a36c10d474c997954597705bffb@haskell.org> #1042: Floating point exception ------------------------------------------------+-------------------------- Reporter: dons | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect result at runtime | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: #8695 ------------------------------------------------+-------------------------- Changes (by hvr): * failure: => Incorrect result at runtime * related: => #8695 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 21:23:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 21:23:51 -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.1564d9d5d30fa736e669a05a91a34b28@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Changes (by hvr): * status: new => patch * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 21:28:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 21:28:56 -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.02c4ad5487346eac4b2a203152ce4886@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by carter): great! seems like theres a principaled justification and the patch is simple. woot -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 21:31:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 21:31:06 -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.f1f0fd366f937cf2d07173008584519c@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by rleslie): Excellent. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 21:35:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 21:35:34 -0000 Subject: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper In-Reply-To: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> References: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> Message-ID: <059.6dda10ed31bb92c9c7cd5a9a29060db1@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by crockeea): * cc: ecrockett0@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 21:37:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 21:37:52 -0000 Subject: [GHC] #8285: unexpected behavior with encodeFloat on large inputs In-Reply-To: <045.f7eaecd94e96f3fd291d7a1c2d15ebef@haskell.org> References: <045.f7eaecd94e96f3fd291d7a1c2d15ebef@haskell.org> Message-ID: <060.0f549b16330f0098dde9d5e3ea77cf24@haskell.org> #8285: unexpected behavior with encodeFloat on large inputs ------------------------------------------------+-------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by hvr): Fwiw, `encodeFloat 1 (2^31)` behaves just like the C99 function [http://pubs.opengroup.org/onlinepubs/7999959899/functions/ldexp.html ldexp(3)] does for those arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 21:58:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 21:58:25 -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.f447c1a4f32b52fc7dd52f7ee7fe6b4b@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by rwbarton): Choosing the behavior to match the existing documentation is the wrong way around, in my opinion. If the current behavior is considered desirable, then there is a documentation bug, not a bug in the definition of division. Unfortunately, there is no choice of behavior that is best in all contexts. For the kinds of programs I most often write, which are computations I run on my own computer, raising an exception is preferable ("safer"). I'm likely to not consider the possibility of dividing `MIN_INT` by `-1`, and the exception protects me: If my program runs to completion, then I know the answer is correct (and that such a division never occurred). In the unlikely event that I do get an exception, then I can consider what to do in the event of such a division and ensure that it is treated properly. If the division silently produces `MIN_INT` then there's some chance that this was the correct thing to do in my context, and some chance that I silently got a nonsense answer, which to me is the worst possible outcome. On the other hand, for someone who is writing a server to, say, evaluate arithmetic expressions, it is a pain if a malicious user can crash the server by asking it to evaluate `MIN_INT / (-1)`, and there's not really any sense in which answers are "right" or "wrong" anyways. For a program that does division and then does something with the result (like indexing into an array) I tend to worry about the security implications of working with a result that may not be expected by the developer (though something has likely gone wrong already, in the specific event that we are dividing `MIN_INT` by `-1`). Personally I am against this change because it would make ghc less useful for me. Moreover, I tend to feel that servers are complicated bits of software that are prone to crashing for many other reasons already, and it is prudent to ensure that an exception raised while handling one request cannot bring down the whole server anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 22:09:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 22:09:40 -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.8a53884b3266f6c4031878a61b03d670@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by rwbarton): Edward, to be a Euclidean domain, `Int` would first of all have to be a domain, which it is not. (I don't think this is nit-picking because there are usually several possible definitions of concepts like "Euclidean domain", which are equivalent under the assumption (here) that the ring is an integral domain. It's potentially more or less an accident which equivalent definition becomes accepted as The Definition, and there's no reason to think it has any distinguished status when the assumption is broken.) The algebraic law that I expect from division with limited-range numeric types is > if `a, b, c :: Int` and `div a b == c` then `div (toInteger a) (toInteger b) == toInteger c`. In my opinion this is a lot more useful than a law involving `fromInteger :: Integer -> Int`, which doesn't play nicely with division. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 22:22:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 22:22:15 -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.45e77e2870ccd797f831967c12046729@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by rleslie): It seems to me there is a desire for a fixed-precision integer type that throws an exception on overflow rather than performing modulo arithmetic -- in which case, I'd be fine with the present behavior, as long as all other overflow conditions were treated similarly. But modulo arithmetic is also useful and desirable for some purposes, and I object to an integer type that performs modulo arithmetic in some cases, and throws an exception in others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 22:25:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 22:25:24 -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.a2da1ed1c94e099a5e2d9ffe4774877a@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by carter): rleslie, have you considered using Word rather than Int in your use case? i think this ticket raises a valid issue, and the proposal is a possibly valid one. But perhaps it should be evaluated on a slightly less compressed time scale as apart of a systematic program to incrementally improve the ghc numerical prelude and such? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 22:31:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 22:31:51 -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.aeb066c63b496ef89bb5483d0ac73173@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by carter): I agree we should have "wrapping" overflow and "trapping/excepting" overflow variants. In fact, i emphatically agree. perhaps it would be more effective if we work out a design for such a future rather than whack more on the current quirky kludge? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 22:38:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 22:38:00 -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.bded9ce9912abb0bf26e0eeeded12af4@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by carter): relevant to this discussion, heres the relevant paragraph in H2010 report section 6.4 http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1350006.4 The standard numeric types are listed in Table 6.1. The finite-precision integer type Int covers at least the range [ ? 229, 229 ? 1]. As Int is an instance of the Bounded class, maxBound and minBound can be used to determine the exact Int range defined by an implementation. Float is implementation-defined; it is desirable that this type be at least equal in range and precision to the IEEE single-precision type. Similarly, Double should cover IEEE double-precision. The results of exceptional conditions (such as overflow or underflow) on the fixed-precision numeric types are undefined; an implementation may choose error (?, semantically), a truncated value, or a special value such as infinity, indefinite, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 22:42:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 22:42:33 -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.fbad696afa009c9eb085856368a00644@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by carter): the referenced table is {{{ Integer, Integra,l Arbitrary-precision integers Int, Integral, Fixed-precision integers (Integral a) => Ratio a, RealFrac, Rational numbers Float, RealFloat, Real floating-point, single precision Double, RealFloat, Real floating-point, double precision (RealFloat a) => Complex a, Floating, Complex floating-point }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 23:00:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 23:00:27 -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.659b56a03e0631e1409569eff1de9a5b@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by hvr): Replying to [comment:14 rwbarton]: > [...] > Unfortunately, there is no choice of behavior that is best in all contexts. For the kinds of programs I most often write, which are computations I run on my own computer, raising an exception is preferable ("safer"). > [...] IMHO, different types should be used for different contexts. If you want exceptions on any kind of overflow, use something like hackage:safeint, if you don't want overflows at all, use `Integer`, and if want wrap-around on overflow, use plain `Int`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 23:14:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 23:14:18 -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.5ac88188f1212bf8c72b85a9931963bd@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by ekmett): rwbarton: I fully expected to get dinged on the fact that Int can't be a proper domain. I should have included the caveat that it is 'insofar as it can be'. That said, when a function can be continuously extended sensibly in only one way, I tend to favor extending it. Re: `div (toInteger a) (-1) == toInteger c`, here `(-1)` is a even unit of `Z mod 2^n`, but we can't even multiply it by all of the ring and pass that law. The only way to pass your condition without partiality would be to use 1s complement to fix the asymmetry between positive and negative values, but it of course comes with all sorts of other problems and is a complete non- starter. That said, the operation can pass a slightly different condition, which is that the answers match mod 2^n. In other words {{{ c = div a b = fromInteger (div (toInteger a) (toInteger b)) }}} {{{ >>> fromInteger $ toInteger (minBound :: Int) `div` (-1) :: Int -9223372036854775808 >>> fromInteger $ toInteger (minBound :: Int) `quot` (-1) :: Int -9223372036854775808 }}} This extension to `div` and `quot` complies with doing this operation in the larger `Integer` domain and coming back down into the restricted range, just like `(*)`, `(-)`, `(+)`, etc. do. Those operations also don't comply with your desired law. carter: There are multiple packages that provide overflow protection. e.g. http://hackage.haskell.org/package/safeint That said, `Int` explicitly does not. 2s complement introduces particularly hairy corner cases around `minBound`. `-minBound = minBound`, `abs minBound < (0 :: Int)` etc. and it is that same counter-intuitive corner case arising here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 23:28:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 23:28:36 -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.46c7ee2f92387cfec469fe80afa64985@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by rwbarton): Division is a totally different kind of operation than addition, subtraction and multiplication! The reason that "performing arithmetic mod 2^n^" is sensible for the latter three is that they respect equality mod 2^n^ (Z/2^n^Z is a ring). Division does not. You can't take the Euclidean domain approach to defining division mod 2^n^ anyways because there are extra solutions, e.g. for `div 100 3` (mod 2^32^) we have 100 = 3 * 33 + 1, but also 100 = 3 * 1431655798 + 2 and 100 = 3 * 2863311564 + 0. The only sensible notion of division mod 2^n^ is modular division by odd numbers, but that's clearly not the role of `div` or `quot`. So I don't give any weight to arguments-by-analogy such as "addition, subtraction and multiplication can be computed by injecting into Integer, performing the operation and reducing the result to an Int, hence so too should division be". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 28 23:45:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Jan 2014 23:45:13 -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.4f4a64c8bd59eb3da4ec80548b2dd098@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by rwbarton): Basically, I don't agree that `minBound :: Int` is a sensible value for `div minBound (-1) :: Int`. Division and modular arithmetic are fundamentally incompatible, so if you are using `div` or `quot` on `Int`s, you are not using `Int` for modular arithmetic but rather to compute more efficiently with integers that happen to be small. And as integers, `-2147483648` divided by `-1` is not `-2147483648`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 00:54:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 00:54:49 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.6ea45bb9c6dac8fdd97a175e50dc2e17@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kazu-yamamoto): Duncan, would you merge the patch ASAP? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 01:05:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 01:05:36 -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.be441026c7f63ae0516c7291fb16ff91@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by lerkok): For whatever it is worth, the SMT community has faced this issue in the past. Their axiomatization implies`quot minBound (-1) = minBound` holds for all sized types. See here for the axiomatization: http://smtlib.cs.uiowa.edu/logics/QF_BV.smt2 I think most theorem provers take either the approach of leaving it completely undefined, which they have the luxury of, or completing the operation similarly. Having said that, the same axiomatization also speculates `quot x 0 = 0` for any x; and obviously Haskell is not ready to take that plunge quite yet. (Which I actually find quite acceptable; but that's besides the point.) One final thought: We strive for Haskell programs to be "semantically" well defined and yearn for tool support for proofs all the time. Losing this bit of connection from the established theorem proving community would be a shame; if nothing else. In particular, any system that hooks up Haskell to such automated tools would have to provision for such discrepancies. I think it would behoove us to follow the theorem proving community here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 01:24:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 01:24:32 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.041e3a787c4b9ceadb493a895deffdf3@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------ Reporter: guest | Owner: iduhetonas Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2258 -------------------------------------+------------------------------------ Changes (by iduhetonas): * owner: => iduhetonas * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 01:30:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 01:30:49 -0000 Subject: [GHC] #7629: segmentation fault in compiled program, involves gtk, selinux In-Reply-To: <050.8a129ebf871cd7c18311d1d52b2fd310@haskell.org> References: <050.8a129ebf871cd7c18311d1d52b2fd310@haskell.org> Message-ID: <065.8e4c533d9adafdb1c1668dd739f6a9b5@haskell.org> #7629: segmentation fault in compiled program, involves gtk, selinux -------------------------+------------------------------------------------- Reporter: | Owner: simonmar wgmitchener | Status: closed Type: bug | Milestone: 7.6.2 Priority: high | Version: 7.4.2 Component: | Keywords: segmentation fault, Runtime System | multithreading, selinux, gtk Resolution: | Architecture: x86 fixed | Difficulty: Unknown Operating System: | Blocked By: Linux | Related Tickets: Type of failure: | Runtime crash | Test Case: | Blocking: | -------------------------+------------------------------------------------- Changes (by juhpetersen): * cc: simonmar (added) Comment: I note for the record that this didn't make ghc-7.6.3 but will be in ghc-7.8. I am finally backporting the patch to Fedora now. wgmitchener: Thank you again for fixing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 02:24:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 02:24:50 -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.ebfba8ba3fa1958ad2e7446a3a8cb26f@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by carter): @lerkok isn't that tantamount to having the 2s complement ops defined as being the same operationally as the unsigned operations of the same size? you make an interesting point, At the same time haskell has more in common with coq / agda tradition than the SMT, though this is an informative remark. @hvr, so heres the thing, one thing i want to dig into in the near future (among several) is improve the native Int / Word / Float / Double optimizations, in both the "correct/no ____flow" and "who cares about underflow/overflow" variants (the latter corresponding to -ffast-math in gcc / clang / llvm). Its kinda hard to provide decent optimization for those respective cases with the former is done as a userland library. Also, theres the fact that, to keep compatibility for the near term, we'd probably have the default int/ word be the wrap around one, BUT we'd probably want to encourage new users to use a sounder default. Its not about either or, but both. (I may have been a bit anti both the last time this debate) I really really want to be able to help ghc have better numerical optimization, on both the bit fiddling and floating fronts. To do that, having clear cases when we want to preserve values in an (over/under)flow / NAN etc evading way is key for those who want to work in the "theres a clear unique solution". Theres actually at least 3 different valid semantics for dealing with over/underflow for words/ints a) exception / interrupts on over/underflow etc b) wrapping style semantics c) saturating (theres a max and min value, you can't go farther than that), this is more common on embedded systems / signal processing algorithms than on desktop/server settings, but its another valid "give a unique solution" approach, and many architectures give instructions for this semantics too. the point being, the curren situation is a mess, and this whole discussion is symptomatic of a deeper problem that really gets in the way of improving the numerical sitch for ghc / haskell. Either solution is not unique, both are valid in different models, and currently theres not a clear stance on which model int's clearly fall on either side, because we're not providing consistent semantic models. in summary: theres several different ways we can give unique semantics to many of these operations, and i don't think the current Int situation sits clearly on either side, and perhaps we should seriously consider what the implications of only providing one choice in semantics in ghc is, and either do it whole sale or provide both. Providing both would actually be in alignment with some of the ideas i have for slightly decoupling Int proper from how array addressing works (because currently int is used implicitly as our model for doing address arithmetic on pointers, which even modern C has moved away from!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 02:31:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 02:31:08 -0000 Subject: [GHC] #8711: StaticValues language extension In-Reply-To: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> References: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> Message-ID: <071.613f00891879c6b76c61e448951d9f4b@haskell.org> #8711: StaticValues language extension -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: closed Type: feature request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Project (more Type of failure: None/Unknown | than a week) Test Case: | Blocked By: Blocking: | Related Tickets: #8107 -------------------------------------+------------------------------------- Changes (by carter): * status: new => closed * resolution: => duplicate Comment: Since the only thing lacking in ghc for this proposal to work as a user land lib (as its envisioned) is the static data / value support, and I've some work on that that I hope to be ready and merged in before ghc 7.10 comes around, i'm closing it as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 05:14:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 05:14:06 -0000 Subject: [GHC] #8712: Data.Ix missing info on row/column major indexing Message-ID: <044.f15edd3b54942a87b830ef4632f57c7e@haskell.org> #8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 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: | -------------------------------------+------------------------------------- I've tried to use {{{Data.Ix}}} with {{{Data.Vector}}} for image manipulations and I confused column with row-major indexing. I expected than {{{Data.Ix.index ((0,0),(3,3)) (1,0) == 1}}} while it is actually equal to 4. Documentation for {{{Data.Ix}}} should explicitly state that it is row- major indexing and function {{{Data.Ix.index}}} might be accompanied by example like: {{{index ((0,0),(3,3)) (1,0) == 4}}} which should be obvious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 06:10:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 06:10:22 -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.18812760854df511f20b6c0dbb1485c1@haskell.org> #8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: new 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 carter): Hey Mirpa, i warmly recommend not using Ix and Array types from base when indexing into multidimensional arrays, juicy pixels has some decent bare bones facilities that should be easier to use http://hackage.haskell.org/package/JuicyPixels-3.1.3.2/docs/Codec- Picture.html likewise, I have some work in progress apis for multi dimensional arrays i hope to release soon. alternatively, REPA, YARR and/or ACCELERATE are all nice libs that can really shine on image related work loads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 07:42:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 07:42:31 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.79af2314f41eef1978f9e0ac8deb8860@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: merge Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Changes (by juhpetersen): * cc: simonmar (added) Comment: Replying to [comment:26 ezyang]: > Perhaps some library HSbase is using has an executable stack? Maybe the build should be cleaned and tried again? I am pretty sure I was testing with a fresh build from the buildsystem. I thought HSbase.o is only used by ghci? Is it also used by other parts? (I tried also dynamic linking with unpatched ghc-7.6.3 and it also leads to executable stack.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 08:43:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 08:43:39 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.05bec1ba43af4fb798d6da9ee2dd6f03@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: merge Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by juhpetersen): Replying to [comment:23 juhpetersen]: > (I noticed that HSbase*.o has executable stack set but I guess that should not affect this, right?) Actually for unpatched ghc-7.6.3 (testing on i686) /usr/lib/ghc-7.6.3/base-4.6.0.1/HSbase-4.6.0.1.o does not seems to have .note.GNU-stack Anyway something must be different in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 10:54:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 10:54:39 -0000 Subject: [GHC] #8711: StaticValues language extension In-Reply-To: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> References: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> Message-ID: <071.a614ef3f6f572f0f772b740137441aa7@haskell.org> #8711: StaticValues language extension -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: closed Type: feature request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Project (more Type of failure: None/Unknown | than a week) Test Case: | Blocked By: Blocking: | Related Tickets: #8107 -------------------------------------+------------------------------------- Changes (by mboes): * cc: 0xbadcode@? (added) Comment: Carter, closing this ticket as "duplicate" of some as of yet completely unspecified, future (!) work of yours with no concrete ETA is really quite rude and territorial. This ticket is about implementing a concrete proposal, which has been made before by others (the distributed-process developers, and the "Towards Haskell in the Cloud" authors). You seem to forget that this ticket is about a feature, independent of any implementation, and moreover independent of who carries it out. If you would like to help implement a feature that covers all the Cloud Haskell use cases, then we'd be happy to collaborate, because this is something that we at Tweag I/O are committed to allocate some of our own resources to have fixed. If that feature moreover happens to cover other use cases related to numeric computations, all the better! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 10:57:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 10:57:44 -0000 Subject: [GHC] #8711: StaticValues language extension In-Reply-To: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> References: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> Message-ID: <071.7234d362105a758d2cec1d36986ae86f@haskell.org> #8711: StaticValues language extension -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: closed Type: feature request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Project (more Type of failure: None/Unknown | than a week) Test Case: | Blocked By: Blocking: | Related Tickets: #8107 -------------------------------------+------------------------------------- Comment (by mboes): As it happens, there already exists a ticket for implementing the proposal made in the Cloud Haskell paper, numbered #7015 by Edsko. So let's continue the discussion there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 11:00:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 11:00:09 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.c3cff267ccd78e98c1ea82cf5a5880a7@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.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 mboes): Relevant thread on the GHC Users mailing list: http://www.haskell.org/pipermail/glasgow-haskell- users/2014-January/024571.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 11:00:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 11:00:34 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.4bcc33dfb28eca40813fcbbdb93380b4@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by mboes): * cc: 0xbadcode@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 11:48:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 11:48:22 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.5f3aa7f2e359b803c896a3b74a45f5a8@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by facundo.dominguez): * cc: facundominguez@? (added) Comment: A design proposal was submitted and discussed in [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-January/024571.html this thread]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 13:13:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 13:13:21 -0000 Subject: [GHC] #8711: StaticValues language extension In-Reply-To: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> References: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> Message-ID: <071.d5e28ccacf4a865286cbc49c6dce113c@haskell.org> #8711: StaticValues language extension -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: closed Type: feature request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Project (more Type of failure: None/Unknown | than a week) Test Case: | Blocked By: Blocking: | Related Tickets: #8107 -------------------------------------+------------------------------------- Changes (by hyperthunk): * cc: watson.timothy@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 13:13:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 13:13:37 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.dc45e5b7f98431c4ed85a4715e738ff3@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hyperthunk): * cc: watson.timothy@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 13:22:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 13:22:09 -0000 Subject: [GHC] #8713: libdl, libpthread may be unwanted too Message-ID: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> #8713: libdl, libpthread may be unwanted too -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: Other Architecture: x86_64 (amd64) | Type of failure: GHC doesn't work Difficulty: Moderate (less | at all than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I have GHC on an unusual system [1] libdl.so.1, librt.so.1 and some others are "filter libraries": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linking is successful, libFOO.so.1 is not linked in :-) Unfortunately, runtime linker (ld.so.1) does not understand GNU ld linker scripts. And I get errors like this: {{{ # ghci -package unix GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package unix-2.7.0.0 ... : can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so (ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc- solaris2.11/4.7/../../../x86_64-illumos/libdl.so: unknown file type) }}} The unix package v2.6 had the same issue with librt.so too, in version 2.7 libdl.so remains. I use the attached patch for GHC 7.6.3 to fix this issue. In general I suggest to use AC_SEARCH_LIBS instead of AC_CHECK_LIB [1] http://osdyson.org -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 14:29:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 14:29:40 -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.f70e54429d85a03f84af2ce69c82d329@haskell.org> #8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: new 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 rwbarton): Um, there's absolutely nothing wrong with using Ix and Array with multidimensional arrays (though the poster is not using Array anyways). Anyways, the Haskell 2010 (or 98) Report does specify that the Ix instance for `(a,b)` uses row-major order (though the wording is awkward: an instance for a built-in type is normally not called "derived"), so I agree that information should appear in the haddocks for Data.Ix somewhere. Incidentally there is a broken link at the end of http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Ix.html which ought to point to the relevant part of the Report, but as I mentioned "Deriving Instances of Ix" is not an intuitive section to look at for the instance `(a,b)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 15:21:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 15:21:56 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.2879c2e180b21f4b5bca1495ca52d91b@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T7478 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 15:21:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 15:21:59 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.31511b231c61ad2919a1bb7c607c1525@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by thoughtpolice): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 15:22:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 15:22:45 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.3134d6af0925d2a10d2c23399e422386@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 15:41:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 15:41:55 -0000 Subject: [GHC] #8699: Multiple test faliures on 32-bit Linux systems. In-Reply-To: <047.0a18fb8eba467de4cead3e8638814c85@haskell.org> References: <047.0a18fb8eba467de4cead3e8638814c85@haskell.org> Message-ID: <062.dfa877054b63e415d7fdf5b835af4707@haskell.org> #8699: Multiple test faliures on 32-bit Linux systems. -------------------------------------+----------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+----------------------------- Comment (by Fuuzetsu): Considering 7.8 branch got created today, here are the tests as of today. Posted in the same order. Links to full output at the bottom. {{{ Unexpected results from: TEST="T1969 haddock.Cabal" OVERALL SUMMARY for test run started at Wed Jan 29 15:14:03 2014 GMT 0:19:10 spent to go through 3883 total tests, which gave rise to 15172 test cases, of which 11625 were skipped 28 had missing libraries 3459 expected passes 58 expected failures 3 caused framework failures 0 unexpected passes 2 unexpected failures Unexpected failures: perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) }}} {{{ Unexpected results from: TEST="T1969 haddock.Cabal haddock.compiler T7859" OVERALL SUMMARY for test run started at Wed Jan 29 14:48:08 2014 GMT 0:11:52 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3452 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 4 unexpected failures Unexpected failures: perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) runghc T7859 [bad stderr] (normal) }}} {{{ Unexpected results from: TEST="haddock.compiler T1969" OVERALL SUMMARY for test run started at Wed Jan 29 14:43:32 2014 GMT 0:09:29 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3454 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 2 unexpected failures Unexpected failures: perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) }}} http://fuuzetsu.co.uk/misc/validate-misaki- 466d06914312bce40647f3e4f4d523964cc6a588 http://fuuzetsu.co.uk/misc/validate-yuuki- 466d06914312bce40647f3e4f4d523964cc6a588 http://fuuzetsu.co.uk/misc/validate-lenalee- 466d06914312bce40647f3e4f4d523964cc6a588 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 17:37:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 17:37:34 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.66d48c45fce492c3817b9f0dc848ca7e@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): With the patch above, the benefits from foldl-via-buildr and the call arity analysis are {{{ Min -0.2% -74.5% -9.6% -10.6% -50.0% Max +0.9% +1.7% +4.1% +4.1% +6.3% Geometric Mean -0.0% -4.0% -0.6% -0.7% -0.7% }}} with only one increase: `nucleic2`. It comes from a use of `maximum`, and it goes away when that is changed from `NOINLINE [1]` to `INLINE [1]` (GHC was inlining `maximum` while `foldl` was implemented naively, but not any more, so let's give it a push). Then we get the very pleasing result of no single benchmark with allocation increase: {{{ Min -0.1% -74.5% -6.8% -8.3% -50.0% Max +0.2% 0.0% +38.5% +38.5% 0.0% Geometric Mean -0.0% -4.1% +7.7% +7.7% -0.8% }}} This is the current state in the branch `wip/T7994-calledArity` of ghc, and the branch `wip/T7994` of base. The effect on compilation times needs to be measured, and quite possibly improved (e.g. not a full simplifier run after it, but only eta-expansion where possible and then a gentle simplification of the RHS). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 17:40:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 17:40:14 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.2b302bc83c01b7c71e05d692fd65baa2@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by nomeata): I occasionally have that as well; right now in `library/base`: {{{ HC [stage 1] libraries/base/dist-install/build/Control/Applicative.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140129 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: base:Control.Applicative.$fApplicativeWrappedMonad{v ri} [(0c7, Identifier ?base:Control.Applicative.<*>{v 0c7}?), (0c8, Identifier ?base:Control.Applicative.pure{v 0c8}?), (0c9, Class ?base:Control.Applicative.Alternative{tc 0c9}?), ... }}} Thorough cleaning helps. Sorry, no further clues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 17:59:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 17:59:56 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.03d0f7192021072838116317f5760d48@haskell.org> #2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => patch Comment: With `master` open for new stuff, I?d like to get this there, preferably within the next one or two weeks, to reduce the number of my patches that are floating around, so I?m marking this as please review. Open tasks are * Fixing the matching against `unsafeCoerce` (needs thought) * Actually adding rules to the libraries. * Documenting this somewhere I?ll open separate tickets for these once this one is in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 18:06:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 18:06:52 -0000 Subject: [GHC] #4267: Strictness analyser is to conservative about passing a boxed parameter In-Reply-To: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> References: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> Message-ID: <059.1a420c43e1c1fd0a99e6f2571589c11a@haskell.org> #4267: Strictness analyser is to conservative about passing a boxed parameter -------------------------------------+------------------------------------ Reporter: tibbe | Owner: nomeata Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Unfortunately, #7994 would break this test ;-) {{{ bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected bytes allocated: 130000 +/-10% Lower bound bytes allocated: 117000 Upper bound bytes allocated: 143000 Actual bytes allocated: 40992 *** unexpected failure for T4267(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 18:14:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 18:14:57 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error Message-ID: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error ----------------------------------+------------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- The attached program produces an core lint error when compiling with optimization. {{{ $ ghc -O -debug -dcore-lint Main [1 of 1] Compiling Main ( Main.hs, Main.o ) *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}) *** : Warning: In the type ?cache_s16y? @ cache_s16y is out of scope *** Offending Program *** Main.focusAst :: forall syntax_aB4. GHC.Types.Int -> Main.BufferImpl syntax_aB4 -> Main.BufferImpl syntax_aB4 [LclIdX, Arity=2, Str=DmdType m, Unf=Unf{Src=InlineStable, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=False) Tmpl= \ (@ syntax_aMw) (r_aB5 [Occ=Once] :: GHC.Types.Int) (b_aB6 [Occ=Once!] :: Main.BufferImpl syntax_aMw) -> case b_aB6 of _ [Occ=Dead, Dmd=] { Main.FBufferData ds_dOP [Occ=Once!, Dmd=] -> case ds_dOP of _ [Occ=Dead, Dmd=] { Main.HLState @ cache_s16y dt_s16z [Dmd=] cache_s16A [Occ=Once, Dmd=] -> case dt_s16z r_aB5 cache_s16A of dt_XBQ { __DEFAULT -> Main.FBufferData @ syntax_aMw (Main.HLState @ syntax_aMw @ cache_s16y dt_s16z dt_XBQ) } } }}] Main.focusAst = \ (@ syntax_aMw) (r_aB5 :: GHC.Types.Int) (b_aB6 :: Main.BufferImpl syntax_aMw) -> case b_aB6 of _ [Occ=Dead, Dmd=] { Main.FBufferData ds_dOP [Dmd=] -> case ds_dOP of _ [Occ=Dead] { Main.HLState @ cache_s220 dt_s221 cache_s222 -> case dt_s221 r_aB5 cache_s222 of dt_XBQ { __DEFAULT -> Main.FBufferData @ syntax_aMw (Main.HLState @ syntax_aMw @ cache_s220 dt_s221 dt_XBQ) } } } }}} The full log is attached. The same error occurs with a GHC HEAD build from 2012/12/12. I will check with a latest HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 19:11:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 19:11:19 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.ce7c69b80c867676b4fb9b2d3602168a@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Fuuzetsu): I tried with HEAD I built earlier today and I don't seem to be able to reproduce on 32-bit Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 19:40:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 19:40:08 -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.0417ffc85473720b3ac1ea7cf0e34f78@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Replying to [ticket:8684 nh2]: > Is that true? This would work fine for Unix. It would be good to test if it does the right thing with CancelSynchronousIO as well. > Also, does {{{interruptible}}}, apart from allowing the function to be interrupted, behave more like {{{safe}}} or {{{unsafe}}}? Interruptible acts like {{{safe}}}, except for the extra signal throwing behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 20:18:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 20:18:11 -0000 Subject: [GHC] #8715: Prompt stays at | instead of going back to > when pressing C-c in multi-line blocks. Message-ID: <054.56cf1d54c85fcdce4b387a48fd13db02@haskell.org> #8715: Prompt stays at | instead of going back to > when pressing C-c in multi- line blocks. -------------------------------------------+-------------------------- Reporter: RobinHoksbergen | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Easy (less than 1 hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------+-------------------------- Starting a block of code in GHCi is done by writing :{, upon which the prompt changes from '>' to '|'. Pressing C-c cancels the block of code, but the '|' prompt remains. This can be somewhat confusing in that it appears GHCi is still stuck in the current block of code, but returns an "unknown command ':}'" when trying to close it. Reproduction steps: * Run GHCi * Start a multi-line block with ':{' * (Optional) Write some code. * Close the block with C-c. * The block will now be closed, but the prompt remains. Opening and closing a new block using the same syntax did not solve the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 20:22:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 20:22:56 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.9c0cbd5095e567b87dab1ebbd0f24a87@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by CoreyOConnor): I just re-built ghc-7.8 branch on linux 64bit and Mac 64bit. SHA: 1bf47fddd62f1d9f0ab3303658c0ae68f225a6d4 This still exhibits the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 20:35:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 20:35:26 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.8279985aa43ec1fa0a150764166ae00f@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by bgamari): * cc: bgamari@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 21:02:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 21:02:44 -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.e159fc6bb75cd7d23455f29d61347a29@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nh2): Replying to [comment:1 ezyang]: > This would work fine for Unix. It would be good to test if it does the right thing with CancelSynchronousIO as well. Ah, great. I guess we should update the documentation until this is actually implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 21:18:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 21:18:15 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.11a16b5f4a5e5ed261ca694770ade916@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by CoreyOConnor): The lint error no longer shows up if the strictness annotation is removed form hlCache of FBufferData. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 22:57:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 22:57:41 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.6bafb15a65dcf593a7a3ccf5f29f2a68@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by yoeight): Thanks for your comments. About `foldM` and `go`, I thought I could traverse `tys` and apply the resulted type in one pass. Using `repTapps` is not as direct. Anyway, I ported the code to `repTapps` as it seems more appropriate. `foldM` and `go` looked too obfuscated. So as you suggested, `EqualityT` is now a nullary constructor and nullary type families are now supported. Let me now if there's any missing use case. Thanks again for your concern and time, don't worry I don't need to be mothered :-). Being offended by helping comments would be inconsistent with my 'How ghc works ?' goal. Updated patches are [https://gist.github.com/YoEight/8370987 here] Also do you have any idea why `testsuite/tests/perf/compiler/T4801.hs` fails ? It's the only failure I got so far. Regards, Yorick -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 29 23:03:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Jan 2014 23:03:36 -0000 Subject: [GHC] #8715: Prompt stays at | instead of going back to > when pressing C-c in multi-line blocks. In-Reply-To: <054.56cf1d54c85fcdce4b387a48fd13db02@haskell.org> References: <054.56cf1d54c85fcdce4b387a48fd13db02@haskell.org> Message-ID: <069.003fa6d564e60a0f424e2037fbefd1b7@haskell.org> #8715: Prompt stays at | instead of going back to > when pressing C-c in multi- line blocks. -------------------------------+------------------------------------------- Reporter: | Owner: RobinHoksbergen | Status: closed Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: GHCi | Keywords: Resolution: duplicate | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------+------------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report; it's a duplicate of #5209. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 00:03:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 00:03:47 -0000 Subject: [GHC] #8716: improve AMP join warning Message-ID: <045.d09131c80ac8da9f457a269f3c27dc3f@haskell.org> #8716: improve AMP join warning ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Any module that defines a top-level join gets this error: {{{ Local definition of ?join? clashes with a future Prelude name - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. }}} This file triggers the warning, but it will keep on working when Prelude exports join: {{{ module M1 (M.join) where join x = x }}} This file will break when Prelude exports join, but there is no warning currently given. {{{ module M2 where import M1 (join) f x = join }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 02:31:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 02:31:13 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.116d4c10a3174b7165e21f2b2af7b55a@haskell.org> #2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * cc: eir@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 02:59:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 02:59:11 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.b389617870d1f8dba97b0dfdccd29f8d@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: merge Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by juhpetersen): Hmm, I retested the patch now on latest ghc-7.6.3 in Fedora 20, and it does indeed fix the execstack issue! So it seems my earlier testing in comment 20 was incorrect, I am sorry! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 03:07:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 03:07:41 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.1629461eda2147eb57ddd0802280de8f@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): Edsko seems to have a good proof of concept that the notion of Static needed for Cloud Haskell is implementable in user land here https://github.com/haskell-distributed/distributed- static/commit/d2bd2ebca5a96ea5df621770e98bfb7a3b745bc7 https://github.com/haskell-distributed/distributed-static/tree/static- with-hsplugins on the static-with-hsplugins branch of distributed-static. it seems like that TH + GHC API / hs-plugin approach edsko has shared gets most of the way there! Is there anything that this solution lacks? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 03:15:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 03:15:34 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.00701f2c0542fb3f1637bb8ace4327be@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: merge Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by juhpetersen): (Just for the record a couple of the ghc-7.6.3 programs in the initial build with the patch still have execstack: hp2ps and unlit. Probably they will go away in a rebuild?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 06:36:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 06:36:13 -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.4100c538177c0dddf3c527dcbf2d6be1@haskell.org> #8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: new 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 mirpa): Thank you for recommendations on libraries. I've heard about Repa. For info: I use {{{FreeType}}} binding to render monochromatic glyphs which gives me {{{ByteString}}} with rows-width-pitch. I convert {{{ByteString}}} into {{{Data.Vector}}} for some number crunching (filtering) and save it as grey scale image with {{{JuicyPixels}}}. {{{Data.Ix}}} is used to address {{{Vector}}} as 2D array. It took me a while before I figured out why there is tearing and/or rotation in my image. I think that appropriate note in documentation could give a vital clue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 09:15:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 09:15:35 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.9c2e31d1f82d3a7e2d151250aad17944@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 10:26:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 10:26:48 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.d889bc98cb80509fba2f15befd131bdd@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: merge Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by juhpetersen): Okay the Saga gets better... I guess my original testing was correct after all: At least in current Fedora the patch seems to fix the problem on i686 but not x86_64! Very weird. This at least explains the above inconsistency in my test results. Just by chance yesterday I was testing #7629 on 32bit and so by chance found this discrepancy - I normally use 64bit. I can't think of anything in the toolchain that should make a difference on 64bit to 32bit though. Anyone have any ideas? The temporary test builds are: i686: http://koji.fedoraproject.org/koji/taskinfo?taskID=6470995 x86_64: http://koji.fedoraproject.org/koji/taskinfo?taskID=6470819 (they will be garbage collected in a week). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 10:37:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 10:37:18 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.d8eeb5696aa1f2176b9c74a5405a8d03@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by NeilMitchell): * cc: ndmitchell@?, simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 10:39:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 10:39:49 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.13d415da9e508053d8ad35d790c58d9f@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 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 augustss): Having something to call might be possible. It would certainly be a start. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 11:54:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 11:54:30 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.d8a0a813b741fa48ffb75d73617ab3cb@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Previously I said that my analysis makes no change in nofib if one does not also change `foldl` to use `foldr`. That is not true anymore with the latest code (but almost so), there are a few allocation improvemts, up to `-1.3%` (in `anna`, stemming from `take 30 [... | ...]`) ? not a surprise, `take` is defined with a continuation passing `takeFB :: (a -> b -> b) -> b -> a -> (Int# -> b) -> Int# -> b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 12:11:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 12:11:33 -0000 Subject: [GHC] #8525: lib/integer/integerConstantFolding fails with -DDEBUG In-Reply-To: <046.5d4a4a7e5e2261c32eff470cf125498f@haskell.org> References: <046.5d4a4a7e5e2261c32eff470cf125498f@haskell.org> Message-ID: <061.0cae45148bfff4585bc4b958cf14fbb1@haskell.org> #8525: lib/integer/integerConstantFolding fails with -DDEBUG -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: integerConstantFolding | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by nomeata): I still get this warning a lot, also when compiling the standard libraries. Is this something to worry about? If so, is this relevant for the 7.8 release? If not; maybe we should remove the warning? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 12:18:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 12:18:32 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.0ab1b1aa4d712581213fbfe975e05ef4@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Despite my initial worries, this analysis is actually quite cheap: A 1.8% increase in compile time (with unchanged libraries), according to nofib (is that the best way to measure it)? Is it worth improving that at the expense of more code in GHC? E.g replace the simplifier pass after CallArity by custom one that just does eta- expansion, and only gently simplifies the expression therein? Or should I just leave it like this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 13:14:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 13:14:31 -0000 Subject: [GHC] #8717: Segfault in 64-bit Windows GHCi Message-ID: <044.52006547921df8c64442c64892015775@haskell.org> #8717: Segfault in 64-bit Windows GHCi ----------------------------------------+------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Difficult (2-5 days) | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------------+------------------------------- This code: {{{ module Bug where import Data.Data c :: Constr c = toConstr False }}} gives segfault when trying to evaluate {{{c}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 13:20:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 13:20:16 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.3f4c2e03c9d6f9f8724ae7f7582d0d1c@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: fixed | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): When battling with https://ghc.haskell.org/trac/ghc/ticket/8717, I've found my patch has a couple of rough edges and one bug. They didn't manifest themselves, though. Please, apply this amendment patch both to 7.8 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 13:22:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 13:22:05 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.660dc7a8068f395e5c3264b9fa892a85@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by awson): * owner: thoughtpolice => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 13:22:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 13:22:41 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.d7af0b320a359532fea21d1dd153e893@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by awson): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 13:23:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 13:23:08 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.25fdfd938b9c12a9eda99e3e7d01ecaa@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by awson): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 13:25:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 13:25:53 -0000 Subject: [GHC] #8700: Cross-compilation perf-cross BuildFlavour In-Reply-To: <045.36b67841d294a8aac5cdb12bc24ba0a0@haskell.org> References: <045.36b67841d294a8aac5cdb12bc24ba0a0@haskell.org> Message-ID: <060.638d24b06e4a851d47b57c22e70e9eb5@haskell.org> #8700: Cross-compilation perf-cross BuildFlavour -------------------------------+------------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Build | Version: 7.8.1-rc1 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged in 99484c965c93df5367ecb3bc29165544baf1da76 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 13:30:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 13:30:06 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.88ebd9340796f99547abbcdbb72f0c2c@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghc-api/T7478 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by MikolajKonarski): BTW, right now (I don't know how it was before) calling `setSessionDynFlags` causes significant memory leaks, visible already in tests with a couple hundred modules and calls. If anybody is interested, I can try to extract a test from my code that uses GHC API, but it's GHC version dependent, etc., so I'd rather not do it until anybody is actively looking at this. But it's straightforward: basically, in a loop: {{{ setSessionDynFlags flags setTargets yetAnotherSIngleModule load LoadAllTargets }}} Even if we load 100 of modules and then just keep reloading the same module, memory will increase all the time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 14:00:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 14:00:38 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.c4c2d2e213a9875b597dfb35a91f58ca@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by duncan): Since the Cabal patch is apparently not necessary, and that I don't yet understand it, then we'll hold off. I do not yet understand the OSX @rpath stuff well enough to see what the consequences would be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 14:47:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 14:47:55 -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.fc299cc6ea626a62720e3781a72cc8dd@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Changes (by lelf): * cc: me@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 14:53:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 14:53:49 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.3b9e833e02ce9020ba55b6217b9aac73@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by thoughtpolice): Awesome, thank you Kyrill. I'm testing this now. (FWIW, you will officially become "Windows Commander in Chief" soon enough if you're not careful... :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 15:13:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 15:13:13 -0000 Subject: [GHC] #8718: Add role annotations to base Message-ID: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> #8718: Add role annotations to base -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- With roles and Coercible in GHC, we ought to add role annotations to base and other libraries. We have them for `Ptr` and `FunPtr`; I guess we need them for * `Map` (first parameter) * `Set` * `Vector` (or rather its primitive building block) What else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 15:23:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 15:23:56 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.ca547ab4419aae34917bd1f2b2173921@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 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 NeilMitchell): Having to call in to dealloc has some issues: 1. When destroying a thread, you need to know if it was ever used for GHC or incurr some overhead. As long as the dealloc is cheap and doesn't require you to have done the alloc, that's OK. 2. You need to know when the thread goes away. If you are using a thread pool library, that's often very tricky. In our particular case it's feasible. 3. If a thread dies unexpectedly the memory will be leaked. That's hopefully not a big issue in practice. So an explicit dealloc is OK for us, with the caveat that is must work successfully on a thread that was never used by GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 17:28:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 17:28:01 -0000 Subject: [GHC] #8719: clarify prefetch release notes + remove some deadcode Message-ID: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> #8719: clarify prefetch release notes + remove some deadcode ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...amend-prefetch- release-notes noticed some deadcode in the -fvia-c related to prefetch, removes that too i have those two as separate commits so they can be handled more easily -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 17:40:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 17:40:12 -0000 Subject: [GHC] #8719: clarify prefetch release notes + remove some deadcode In-Reply-To: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> References: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> Message-ID: <060.05da30bdc21f90611e78987fbd8fc698@haskell.org> #8719: clarify prefetch release notes + remove some deadcode -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): on the email this link got smushed here it is again http://bit.ly/1a45cev -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 18:07:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 18:07:40 -0000 Subject: [GHC] #8718: Add role annotations to base In-Reply-To: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> References: <046.5bf32c0ca4f956dafd133cea02061c35@haskell.org> Message-ID: <061.9749e34bf751b215ac347ea6998fe25e@haskell.org> #8718: Add role annotations to base -------------------------------+------------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 7.6.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by goldfire): See also a very relevant thread starting here: http://www.haskell.org/pipermail/libraries/2013-November/021707.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 18:59:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 18:59:38 -0000 Subject: [GHC] #8711: StaticValues language extension In-Reply-To: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> References: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> Message-ID: <071.69397cc927108df294817d3d297c57fa@haskell.org> #8711: StaticValues language extension -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: closed Type: feature request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Project (more Type of failure: None/Unknown | than a week) Test Case: | Blocked By: Blocking: | Related Tickets: #8107 -------------------------------------+------------------------------------- Comment (by carter): the needs of this ticket seem be satisfiable in user land with https://github.com/haskell-distributed/distributed- static/commit/d2bd2ebca5a96ea5df621770e98bfb7a3b745bc7 today. please keep discourse on trac positive and constructive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 19:52:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 19:52:03 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.f2460b55f575219cc6abebf3e73c3f8b@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by duncan): Replying to [comment:53 duncan]: > Since the Cabal patch is apparently not necessary, and that I don't yet understand it, then we'll hold off. I do not yet understand the OSX @rpath stuff well enough to see what the consequences would be. I've changed my mind (now that I think I understand it). See https://github.com/haskell/cabal/issues/1660#issuecomment-33701508 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 21:42:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 21:42:44 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.79f572738c0b6b8ac62f5bc549a3d91b@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.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 facundo.dominguez): Discussion is also happening [https://groups.google.com/forum/#!topic /parallel-haskell here]. Threads went disjoint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 22:50:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 22:50:25 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.4c7d75fbb0fa007912892128a923aa1f@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"fda9bebc61cab7235123b50dc70dbf30f0140dad/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fda9bebc61cab7235123b50dc70dbf30f0140dad" Fix some edge cases in 8f8bd88c (#7134) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 22:54:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 22:54:23 -0000 Subject: [GHC] #8719: clarify prefetch release notes + remove some deadcode In-Reply-To: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> References: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> Message-ID: <060.84565435c5d94220e0974990c2ff8922@haskell.org> #8719: clarify prefetch release notes + remove some deadcode -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by carter): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 23:07:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 23:07:28 -0000 Subject: [GHC] #8720: ghc crash Message-ID: <044.f80d33b8a7200bf29e1b5ccf24b38d5f@haskell.org> #8720: ghc crash ------------------------------------------------+-------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: ghci crash mvar thread block | Operating System: Architecture: x86_64 (amd64) | Windows Difficulty: Unknown | Type of failure: GHCi Blocked By: | crash Related Tickets: | Test Case: | Blocking: ------------------------------------------------+-------------------------- ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I didn't try to reproduce it, but figured someone might want it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 23:50:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 23:50:21 -0000 Subject: [GHC] #8720: ghc crash In-Reply-To: <044.f80d33b8a7200bf29e1b5ccf24b38d5f@haskell.org> References: <044.f80d33b8a7200bf29e1b5ccf24b38d5f@haskell.org> Message-ID: <059.14ef4b4c82920ea4c3067f9edd41ec4c@haskell.org> #8720: ghc crash --------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: GHCi | Keywords: ghci crash mvar thread block Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Windows | Blocked By: Type of failure: GHCi | Related Tickets: crash | Test Case: | Blocking: | --------------------------+------------------------------------------------ Comment (by Fuuzetsu): You should probably say what you were doing when it happened. Also looks like a duplicate of #4245 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 30 23:53:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Jan 2014 23:53:09 -0000 Subject: [GHC] #8663: Fix up Haddock mark-up In-Reply-To: <047.a5cef90a0af192908b486d98b7c3c24e@haskell.org> References: <047.a5cef90a0af192908b486d98b7c3c24e@haskell.org> Message-ID: <062.5d4797b7c3af3919ca7097ba989fe54d@haskell.org> #8663: Fix up Haddock mark-up --------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by Fuuzetsu): * status: new => closed * resolution: => fixed Comment: This was fixed with r5f2cdca8d745bd47847c3f29c8c32786ce728c8b but it seems someone forgot to close the ticket after doing so. I'm closing it myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 03:14:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 03:14:50 -0000 Subject: [GHC] #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction In-Reply-To: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> References: <048.924a8e6e399ea6a7e72680582970f2bd@haskell.org> Message-ID: <063.0c1d9efb073bdd4ae0c7967e6a75793f@haskell.org> #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction --------------------------------------------+------------------------------ Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by fryguybob): * cc: fryguybob@? (added) Comment: As [comment:2 ezyang] said, this is the expected behavior. We only visit the right branch if the left branch reaches retry. While the effects of the left branch are discarded, the outcome is not. When the whole transaction commits, it will check that the outcome of the left branch is still the same by checking that the reads from the left branch have not changed. This becomes important if the right branch reaches `retry` (and this is a top-level `orElse`). When the transaction blocks, it needs to be added to the watch list for all the `TVar`s read, including the branches that we discarded as it may be the case that an earlier branch will allow the transaction to make progress. Before we can block we must validate that we are not blocking due to reading inconsistent data. Otherwise we could block and miss the chance to wake up. While I think a nondeterministic `orElse` should be possible, it would be tricky to get it right and with the fairness that we would clearly want. I'm not sure what are the right interactions with nesting and blocking. A particular branch could reach `retry` due to inconsistent reads. Do we still propagate the retry up, potentially taking another branch at a higher level? Do we block on this faulty data, or validate the discarded reads first? If found invalid do we start all over, or do we try inconsistent branches again? If so in what order? Perhaps there is some wisdom to be gleaned from this work: http://www.cs.rit.edu/~mtf/research /tx-events/IFL11/techrpt.pdf If you only care about a top-level chain of `orElse`s as in the example, you can sort of accomplish what you want now with something like this: {{{ #!haskell atomicallyOneOf :: [STM a] -> IO a atomicallyOneOf ts = go (cycle (map run ts)) where go (t:ts) = do v <- t case v of Nothing -> go ts Just a -> return a run t = atomically ((Just <$> t) `orElse` return Nothing) }}} But this will still get "stuck" when it runs across a `t` that is contending with a repeated faster transaction. If we had a `tryAtomically` that didn't bother to start again you could do a little better, but I'm not sure this is a good API to give users in general as they might reach for it at the wrong time. The problem might be better addressed in the other direction by avoiding the repeated fast committing transaction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 08:51:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 08:51:54 -0000 Subject: [GHC] #8721: Testsuite not reporting errors for DYN way on OS X Message-ID: <046.8af9e017e06f897fefadc3e624641754@haskell.org> #8721: Testsuite not reporting errors for DYN way on OS X ------------------------------------+---------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: dynamic linking | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- Using GHC 7.6.3, on OS X 10.8.5, for the program: `main = putStrLn "Hello World"`, compiling with `ghc --make -dynamic Main.hs`, I get: {{{ ~/Documents/devel/test$ ./Main dyld: Library not loaded: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.dylib Referenced from: /Users/christiaan/Documents/devel/test/./Main Reason: image not found Trace/BPT trap: 5 }}} The reason for this is that: * I installed GHC in: `/opt/ghc/7.6.3` instead of the default `/usr/local`. * GHC-bundled libraries get an OS X `install_name` with a prefix of `/usr/local/` instead of `/opt/ghc/7.6.3/`, meaning that the runtime linker will be looking in the wrong place. So, I wondered why this bug never showed in the testsuite and decided to test: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ make WAY=dyn TEST=10queens ? =====> 10queens(dyn) 1834 of 3403 [0, 0, 0] cd ./programs/10queens && '/opt/ghc/7.6.3/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history --make -o 10queens Main -O -dynamic >10queens.comp.stderr 2>&1 cd ./programs/10queens && ./10queens 10queens.run.stdout 2>10queens.run.stderr OVERALL SUMMARY for test run started at Fri Jan 31 09:42:45 CET 2014 3403 total tests, which gave rise to 13561 test cases, of which 0 caused framework failures 13560 were skipped 1 expected passes 0 had missing libraries 0 expected failures 0 unexpected passes 0 unexpected failures }}} However, when I run the `10queens` program myself: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ tests/programs/10queens/10queens dyld: Library not loaded: /usr/local/lib/ghc-7.6.3.20130421/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.20130421.dylib Referenced from: /opt/ghc/7.6.3/src/ghc/testsuite/tests/programs/10queens/10queens Reason: image not found Trace/BPT trap: 5 }}} I get a similar error as the one reported above. Due to commit f7be53ac9dac85b83e7fe5ecede01b98a572ba48, these errors will no longer show in GHC 7.8. However, I feel that the testsuite is now giving a false sense of security in terms of dynamic linking. Obviously dynamic linking was broken in 7.6, but the testsuite did not catch it! Sadly, this behaviour can now only be verified in the 7.6 branch, and not in 7.8 or HEAD. Hopefully somebody more knowledgeable of the testsuite can comment why dynamic linking worked when an executable was run "within" the testsuite, whilst being broken when run normally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 09:20:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 09:20:24 -0000 Subject: [GHC] #8713: libdl, libpthread may be unwanted too In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.2fef1e6ccf23589b0a055f959c79fc45@haskell.org> #8713: libdl, libpthread may be unwanted too -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHC doesn't work | Difficulty: Moderate (less at all | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ip1981): I found another issue: {{{ # 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) /usr/lib/gcc/x86_64-pc- solaris2.11/4.7/../../../x86_64-illumos/librt.so ... failed. : user specified .o/.so/.DLL could not be loaded (ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc- solaris2.11/4.7/../../../x86_64-illumos/librt.so: unknown file type) Whilst trying to load: (dynamic) /usr/lib/gcc/x86_64-pc- solaris2.11/4.7/../../../x86_64-illumos/librt.so Additional directories searched: (none) }}} The dyson-libs.patch? patch fixes this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 09:22:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 09:22:21 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) (was: libdl, libpthread may be unwanted too) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.b008c70b81c0e2d89ba803be5ffec37b@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) ----------------------------+---------------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi | Difficulty: Moderate (less than a day) crash | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------+---------------------------------------------- Changes (by ip1981): * cc: hvr (added) * failure: GHC doesn't work at all => GHCi crash * component: libraries/unix => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 09:41:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 09:41:09 -0000 Subject: [GHC] #8721: Testsuite not reporting errors for DYN way on OS X In-Reply-To: <046.8af9e017e06f897fefadc3e624641754@haskell.org> References: <046.8af9e017e06f897fefadc3e624641754@haskell.org> Message-ID: <061.2c1de1f681dfb711cbdc79e0ffe1ee6b@haskell.org> #8721: Testsuite not reporting errors for DYN way on OS X -------------------------------+------------------------------------ Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Comment (by darchon): I guess I can answer my own question, the testsuite sets up a correct `DYLD_LIBRARY_PATH`. Indeed: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ export DYLD_LIBRARY_PATH=/opt/ghc/7.6.3/src/ghc/libraries/base/dist- install/build/:/opt/ghc/7.6.3/src/ghc/libraries/integer-gmp/dist- install/build/:/opt/ghc/7.6.3/src/ghc/libraries/ghc-prim/dist- install/build/:/opt/ghc/7.6.3/src/ghc/rts/dist/build/; tests/programs/10queens/10queens 724 }}} runs the executable without problems. Of course, `DYLD_LIBRARY_PATH` was never set for executables that ran "outside" of the testsuite. So in a way, the testsuite and an installed GHC were "misaligned". Seeing how as of 7.8 the testsuite and an installed GHC are "aligned", I guess the status of this ticket should be turned to either `solved` or `wontfix`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 11:20:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 11:20:21 -0000 Subject: [GHC] #8711: StaticValues language extension In-Reply-To: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> References: <056.25e1a53f8cdf4e387bbe5eda889fa9b7@haskell.org> Message-ID: <071.4cddc1f7842b01ab2f8cc8eee47fe142@haskell.org> #8711: StaticValues language extension -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez facundo.dominguez | Status: closed Type: feature request | Milestone: Priority: normal | Version: Component: Compiler | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Project (more Type of failure: None/Unknown | than a week) Test Case: | Blocked By: Blocking: | Related Tickets: #8107 -------------------------------------+------------------------------------- Comment (by hyperthunk): Not all the use cases (or edge cases for that matter) are covered by that discussion. This ticket is still a duplicate though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 11:21:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 11:21:14 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.6871a901b3d2368bef2b275c3cec8505@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.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 hyperthunk): Indeed - we've not reached a conclusion yet! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 11:26:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 11:26:41 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.7942dffbf3222a2e877306536b657716@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonmar): * owner: => simonmar * priority: normal => highest * milestone: => 7.8.2 Comment: Thinking about it a bit more, it ought to be possible to clean these up automatically. The tricky bit is knowing when to do so - too eager and we penalize threads that are doing frequent in-calls, too lazy and we have the memory leak again. Perhaps just sweeping the table during a major GC would be good enough. Better might be to only free Tasks that have survived one major GC cycle without being used, but that's a bit more work. I'll look into this when I've got some time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 15:07:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 15:07:40 -0000 Subject: [GHC] #8717: Segfault in 64-bit Windows GHCi In-Reply-To: <044.52006547921df8c64442c64892015775@haskell.org> References: <044.52006547921df8c64442c64892015775@haskell.org> Message-ID: <059.d6b20c8093d96fc2a1230d18774c4547@haskell.org> #8717: Segfault in 64-bit Windows GHCi -------------------------------+---------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Difficult (2-5 days) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------------- Comment (by awson): Phew. That was a nightmarish debugging experience. At last, I've found that some code in {{{base}}} wants to access {{{GetCommandLineW}}} not at an exact trampolined address but with {{{+1}}} offset. I am extremely tired, so I've decided to not dig further in {{{GHCi}}} with {{{base}}} interaction and simply exposed {{{GetCommandLineW}}} to {{{GHCi}}} statically. Thus, {{{GetCommandLineW}}} is loaded by a system linker and is not trampolined anymore. This is ugly hack, but it works and makes {{{GHC}}} build, for example, {{{llvm-general}}} package - impossible thing before. This patch applies to 7.8 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 15:08:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 15:08:49 -0000 Subject: [GHC] #8717: Segfault in 64-bit Windows GHCi In-Reply-To: <044.52006547921df8c64442c64892015775@haskell.org> References: <044.52006547921df8c64442c64892015775@haskell.org> Message-ID: <059.e24f8f8b4cdb46b64dc7cdd7415b4656@haskell.org> #8717: Segfault in 64-bit Windows GHCi -------------------------------+---------------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Difficult (2-5 days) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------------- Changes (by awson): * priority: normal => high * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 17:21:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 17:21:49 -0000 Subject: [GHC] #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable Message-ID: <047.811e0564abc56077d47e367aa39c576a@haskell.org> #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable -----------------------------+---------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------------- Building 7.8.RC1 on powerpc64 fails with: {{{ [ 2883s] In file included from rts/sm/GCUtils.h:19:0, [ 2883s] from rts/sm/Scav.c:20: [ 2883s] rts/sm/GCTDecl.h:139:2: error: #error Cannot find a way to declare the thread-local gc variable! [ 2883s] #error Cannot find a way to declare the thread-local gc variable! [ 2883s] ^ [ 2883s] rts/ghc.mk:512: recipe for target 'rts/dist/build/.depend-v-l -debug-thr-thr_debug-thr_l.c_asm' failed [ 2883s] make[1]: *** [rts/dist/build/.depend-v-l-debug-thr-thr_debug- thr_l.c_asm] Error 1 }}} The build is unregisterized (default) and does not use dynamic linking (DYNAMIC_GHC_PROGRAMS=NO and DYNAMIC-BY_DEFAULT=NO). It might be related to #8301. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 21:34:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 21:34:01 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.c389f22b2f50f7e87b53c4a5de117152@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"5671ad66b8c938939a44c883002caa4e13be098c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5671ad66b8c938939a44c883002caa4e13be098c" Update to latest Cabal 1.18 branch tip This update pulls in the fix for #8266 (recommended add-on reading for those interested in OSX linker peculiarities: https://github.com/haskell/cabal/issues/1660#issuecomment-33701508 ) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 22:38:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 22:38:28 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.a4fba1b252a6f5f5b3257e5f68f9a45d@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 31 22:43:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Jan 2014 22:43:13 -0000 Subject: [GHC] #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable In-Reply-To: <047.811e0564abc56077d47e367aa39c576a@haskell.org> References: <047.811e0564abc56077d47e367aa39c576a@haskell.org> Message-ID: <062.0f4601755df022c33fc3f294478f6a1c@haskell.org> #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by trommler): * owner: => trommler * difficulty: Unknown => Easy (less than 1 hour) Comment: The above patch might fix the issue. I will wait for my builds on x86, x86_64 and powerpc64 and then set the ticket to patch. -- Ticket URL: GHC The Glasgow Haskell Compiler