From ghc-devs at haskell.org Tue Apr 1 00:04:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Apr 2014 00:04:29 -0000 Subject: [GHC] #8945: GHC produces grouped declarations in a weird order In-Reply-To: <047.12aea71633961830ba977b69f47ef451@haskell.org> References: <047.12aea71633961830ba977b69f47ef451@haskell.org> Message-ID: <062.5826a265e55cebf79b2f5198e071ac33@haskell.org> #8945: GHC produces grouped declarations in a weird order -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by haasn): I think the issue might actually be in the parser, more specifically in ghc/compiler/parser/Parser.y.pp: {{{ sig_vars :: { Located [Located RdrName] } : sig_vars ',' var { LL ($3 : unLoc $1) } | var { L1 [$1] } ... sigdecl :: { Located (OrdList (LHsDecl RdrName)) } : ... | var ',' sig_vars '::' sigtypedoc { LL $ toOL [ LL $ SigD (TypeSig ($1 : unLoc $3) $5) ] } }}} sig_vars is returning stuff in the opposite order. Seems to me like sig_vars should be changed to use an OrdList and snoc instead of consing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 1 07:41:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Apr 2014 07:41:57 -0000 Subject: [GHC] #8945: GHC produces grouped declarations in a weird order In-Reply-To: <047.12aea71633961830ba977b69f47ef451@haskell.org> References: <047.12aea71633961830ba977b69f47ef451@haskell.org> Message-ID: <062.43f7823f07252a03ec3931e663cf9b00@haskell.org> #8945: GHC produces grouped declarations in a weird order -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Spot on. GHC's front end makes no particular effort to maintain the original declarations in the order they were given. While it was just a front end for the compiler that was fine, but now it's being used for Haddock and other back ends I can see that being more careful about this would be good. I'd be happy to accept a patch. (It's not hard, as you observe.) There may be other places in the parser where this kind of things happens, I'm not sure. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 1 12:15:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Apr 2014 12:15:35 -0000 Subject: [GHC] #8937: Wrong jump target in stg_maskUninterruptiblezh In-Reply-To: <045.b6d0729cad4aed01f58fdf55a078a77f@haskell.org> References: <045.b6d0729cad4aed01f58fdf55a078a77f@haskell.org> Message-ID: <060.eb6d632b255354da71371ebdbd8c26ee@haskell.org> #8937: Wrong jump target in stg_maskUninterruptiblezh -------------------------------------+------------------------------------ Reporter: hsjunn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.2 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): * milestone: => 7.8.2 Comment: Well spotted, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 1 12:24:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Apr 2014 12:24:16 -0000 Subject: [GHC] #8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure In-Reply-To: <043.a14957746ae331f43904850115d79702@haskell.org> References: <043.a14957746ae331f43904850115d79702@haskell.org> Message-ID: <058.e17ff7c4073d0b9e17de66b25599eb27@haskell.org> #8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure -------------------------------+------------------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by simonmar): * status: new => infoneeded Comment: Did you actually encounter a problem? I'm not convinced that falling back to getrusage is the correct thing to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 1 13:07:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Apr 2014 13:07:47 -0000 Subject: [GHC] #8942: Duplicate symbol error when loading an archive twice In-Reply-To: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> References: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> Message-ID: <061.9d31dd83ffbd62d99ed4a5ff69576677@haskell.org> #8942: Duplicate symbol error when loading an archive twice -----------------------------------+------------------------------------ Reporter: gelisam | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Changes (by simonpj): * status: new => patch Comment: Simon M, might you review? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 1 16:52:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Apr 2014 16:52:38 -0000 Subject: [GHC] #8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind" Message-ID: <047.d45db81c2a114a0b8481c5b5010dc503@haskell.org> #8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind" ----------------------------------+--------------------------------- Reporter: tbelaire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I was tying to get hdevtools to work, and cloned it and pulled in a bunch of the open pull requests. You can see the state it's in at github.com/tbelaire/hdevtools. {{{ git clone git at github.com:tbelaire/hdevtools cd hdevtools cabal sandbox init cabal install cd .. }}} I could not reproduce the problem on a small test file, so I'm afraid I'll have to demonstrate it on my vinyl-json package. {{{ git clone git at github.com:tbelaire/vinyl-json cd vinyl-json/ cabal sandbox init cabal install hdevtools type src/Data/Vinyl/JSON.hs 42 15 panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-apple-darwin): Evaluated the place holder for a PostTcKind Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I also get hpc has closed due to a problem a lot when compiling things, but I think that's unrelated. The dynamic lib seems to be gone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 1 17:07:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Apr 2014 17:07:15 -0000 Subject: [GHC] #8945: GHC produces grouped declarations in a weird order In-Reply-To: <047.12aea71633961830ba977b69f47ef451@haskell.org> References: <047.12aea71633961830ba977b69f47ef451@haskell.org> Message-ID: <062.f15fbe317511d00c70ea13ddf895541e@haskell.org> #8945: GHC produces grouped declarations in a weird order -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by haasn): * status: new => patch Comment: Fix located at https://github.com/haasn/ghc/commit/0b51dcae17cc283372304022db2873968a0c6059 Note: I'm not sure how to handle this submodule stuff etc. correctly. Applying this commit will make the Haddock test suite fail, unless we also apply https://github.com/haasn/haddock/commit/bbcf5d385d6b8682884558500e17fdcddf8099af Would it be correct to push bbcf5d38 to Haddock's master, and then update GHC's master to include 0b51dcae which also changes the commit Haddock points to at the same time, to make sure the test suite is always consistent with the change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 1 20:12:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Apr 2014 20:12:38 -0000 Subject: [GHC] #8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind" In-Reply-To: <047.d45db81c2a114a0b8481c5b5010dc503@haskell.org> References: <047.d45db81c2a114a0b8481c5b5010dc503@haskell.org> Message-ID: <062.6ceef0f75af5bc31ace39b9bfe20033c@haskell.org> #8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind" ---------------------------------+---------------------------------- Reporter: tbelaire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | 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 monoidal): Simpler version: install hdevtools, and then create a file A.hs {{{ {-# LANGUAGE DataKinds, KindSignatures #-} module A where data PlainRec :: [*] -> * x = undefined :: PlainRec '[sym] }}} and run `hdevtools type A.hs 1 1`. hdevtools seems to call GHC API, but I didn't get around to finding the offending call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 02:20:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 02:20:33 -0000 Subject: [GHC] #8947: Depending on hint/ghc API fixes the binary version I can use Message-ID: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> #8947: Depending on hint/ghc API fixes the binary version I can use ----------------------------+---------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- When I `build-depend` on hint-0.4.0.0 with GHC 7.6.3, I get {{{ % cabal configure Resolving dependencies... cabal: Could not resolve dependencies: trying: pointcloudviewer-0.1.0 (user goal) trying: hint-0.4.0.0/installed-cf3... (dependency of pointcloudviewer-0.1.0) trying: ghc-7.6.3/installed-494... (dependency of hint-0.4.0.0/installed-cf3...) trying: bin-package-db-0.0.0.0/installed-608... (dependency of ghc-7.6.3/installed-494...) trying: GLUtil-0.7.4/installed-223... (dependency of pointcloudviewer-0.1.0) next goal: linear (dependency of GLUtil-0.7.4/installed-223...) rejecting: linear-1.6/installed-300... (conflict: bin-package-db => binary==0.5.1.1/installed-72e..., linear => binary==0.7.1.0/installed-a33...) }}} This fails because `linear` uses a `binary > 0.5.1.1`, but through my use of `hint` which depends on `ghc` (`hint` does not directly depend on `binary`), I pull in a constraint `binary == 0.5.1.1`. I believe this is bad, because depending on the GHC API in any way fixes the binary version I can use, which immediately makes a range of newer libraries unavailable to my program. Probably GHC should somehow hide the fact that binary is used inside, and let the rest of my program use whatever binary it likes. ---- I am aware that this might not be immediately easy, since the GHC API might expose some `binary` types to my program that I could try use with my newer binary version, which of course would be illegal. Maybe it is possible to implement such a check into actual typechecking, and let it pass if I don't actually use types from the old version with functions from the new library. I actually believe I have seen compiler errors in the past where two identical types where not unified because one was from a different version, so maybe infrastructure for this is already in place? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 05:44:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 05:44:19 -0000 Subject: [GHC] #8948: What Is The Fastest Way Message-ID: <051.f06a6e07b5167aa1089d158bdcb2926a@haskell.org> #8948: What Is The Fastest Way ------------------------------------+------------------------------------- Reporter: sqcbybeddly1 | 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: | ------------------------------------+------------------------------------- [http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia]Every embody write has got a object of its own. Screw for instance, any slenderize man acquire a lowercase assemblage for errors patch buying a agree for him. [http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia]It is exclusive by equalisation their proportions in an due mode that they gift be able to experience a beautify to fit them excavation. In enjoin to engage these men with a rest, a slenderize suit has been stitched. Now no human you beggary to go for the suits that do not fit you decently. So, buy one of these suits and have the identical to exhibit a unequalled call, before you go to buy a accommodate that is meant to fit a thin man, you beggary to originate a few primary steps. Beneath these points are more discussed:[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] E'er go for a appressed fitted causa: If you are object a correspond to fit your slenderize build, it is considered to go for one that is tight fitted. This would definitely sustenance forth any histrion textile moving or ornament out.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] It give be healthy if you can label a cause that is source fitted on the shoulders, dresser, angle, and part. This would surely let you experience a concise fit of what you are act. Today,[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] there are umteen online tally shops that can provide you to get check you are sensing for.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Person the sleeves, the exceed they are: If you start under a bit slim type then e'er go for the suits that hit elongate sleeves.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Tho' it is not considered otherwise,[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] as suits are ordinarily shabby with shorter sleeves so that at least an progress of the shirt relic apparent. This is serviceable so mainly due to flaunt an mesmerizing set of fetter course.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] But, for those who are skinny, it is the different way golf.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] So, score a slenderize gibe that faculty surely play you beautify matters the most:[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] This is the trickiest division in handicraft a causa for a slim man.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Here the lapels, the upper titty incurvature, etc.,[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] are all assumption a due kindness. Tidy trusty to mature a garment for yourself whose lapels materialize to be matched with the breadth of your torso. The modify pockets of the pelage are also required to be virtuous over the hip area of the wearers.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Pockets with surface are also required to be avoided.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] If your coat is vented, it should not excel the area.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] It does not looking great and thus also required to be usurped a eager reparation of.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] So, as you now cognize what are the points required to be preserved while selecting suits online for yourself,[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] try to move these essential guidelines.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] It is exclusive when you uprise these points that you leave be able to pronounce a agree that will fit you befittingly. [http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 08:18:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 08:18:39 -0000 Subject: [GHC] #8948: Profiling report resolution too low Message-ID: <044.a2f3e9dcf4fc7e54f23aaf60dd57adef@haskell.org> #8948: Profiling report resolution too low ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | 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 running criterion benchmarks under profiling, the criterion internals usually dominate the report. That means that the code you actually care about ends up with very low percentages: {{{ individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc ... Full Data.HashMap.Base 360 725180 0.2 0.5 0.4 0.9 Leaf/neq Data.HashMap.Base 364 5151 0.0 0.0 0.0 0.0 BitmapIndexed/update Data.HashMap.Base 362 227250 0.1 0.2 0.2 0.3 BitmapIndexed/insert Data.HashMap.Base 365 78376 0.0 0.0 0.0 0.0 Leaf/neq Data.HashMap.Base 363 132411 0.0 0.1 0.0 0.1 BitmapIndexed/insert Data.HashMap.Base 361 191597 0.0 0.1 0.0 0.1 BitmapIndexed/update Data.HashMap.Base 357 4545 0.0 0.0 0.0 0.0 BitmapIndexed/insert Data.HashMap.Base 359 3030 0.0 0.0 0.0 0.0 Leaf/neq Data.HashMap.Base 358 1515 0.0 0.0 0.0 0.0 BitmapIndexed/insert Data.HashMap.Base 356 1414 0.0 0.0 0.0 0.0 Leaf/neq Data.HashMap.Base 355 101 0.0 0.0 0.0 0.0 Empty Data.HashMap.Base 354 101 0.0 0.0 0.0 0.0 }}} If you're interested in comparing the relative time spent in these functions, that's not really possible as these numbers have too low accuracy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 08:22:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 08:22:23 -0000 Subject: [GHC] #8948: Profiling report resolution too low In-Reply-To: <044.a2f3e9dcf4fc7e54f23aaf60dd57adef@haskell.org> References: <044.a2f3e9dcf4fc7e54f23aaf60dd57adef@haskell.org> Message-ID: <059.79b1735aebef6586200283f0d555162b@haskell.org> #8948: Profiling report resolution too low -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | 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): Using `+RTS -p -P` to output the raw ticks doesn't really help either, as several of the above functions have zero ticks (which is odd) and the rest have 1-29. Is it possible to sample more often? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 08:33:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 08:33:43 -0000 Subject: [GHC] #8948: Profiling report resolution too low In-Reply-To: <044.a2f3e9dcf4fc7e54f23aaf60dd57adef@haskell.org> References: <044.a2f3e9dcf4fc7e54f23aaf60dd57adef@haskell.org> Message-ID: <059.54797394877a190cd2c0a0bcf29b3a69@haskell.org> #8948: Profiling report resolution too low -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | 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 hvr): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 09:29:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 09:29:33 -0000 Subject: [GHC] #8949: The New Slim in 6 Diet Message-ID: <046.588949e3d0bbb3b85e0d08445430cc24@haskell.org> #8949: The New Slim in 6 Diet ------------------------------------+------------------------------------- Reporter: sdvsdv1 | 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: | ------------------------------------+------------------------------------- Beach Body, the corp judicious for the progressive Slim in 6, has just precondition lineage who poverty a better way of period what they require. The adapt of the papers is to let song succeed their paragon metric in a progressively unabated workout. You'll be delighted to fuck the schedule was fashioned to modify to your embody's needs. It testament not scandalize you with too distressful stretches that may substance your muscles. You may begin slow because Debbie, your instructor, knows not to overexert you.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] As you turn improved, the workouts leave conform themselves to what you can do. To attain things fewer complicated, you get further materials to assist along the path. You'll get a fasting draw and travel calendar. Equal the different Beach Body DVDs, they break you a lot of bonuses when you buy their products.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] You get 160 mins designer of workout message for over $60, and it is designer each cent spent. Debbie Siebers, the instructor who present channelise you thru the 6 months, has whatsoever decades of expertise, putting her in the range of an skilful.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] She's expended plume the dawdle of weight departure herself and knows what it is similar to fight with your unit.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Other videos pretence instructors who are not level competent to connect to the coefficient issues that umpteen folks bang.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Debbie is dissimilar because she's been there.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] What folks now hunger for is someone that is jot with fact.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Right tally a perception at the testimonials of the most slaked shoppers and you may undergo the Beach Embody has hit it opportune. When you get the terminated set of the Turn in 6 DVD, you may remark that you are effort more than but a workout.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] The benefits that get unitedly with the aggregation were accessorial to act losing unit a way easier end to movement. Beach Embody,[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] the resolute liable for the DVD put in the succeeding additions:.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] When you acquire your order, you are asked to go thru the whole workout.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] If, at any reading, you're opinion that it's not working for you,[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] there's a 6-week money-back endorse. The Slenderize in 6 gives a predicted timeframe for coefficient diminution results so that you leave cognise what can be foreseen every day.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] If you are clinched on budget, you should get the Slim in 6 using 3 fair monthly installments.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] If you are obsessed almost your prosperity, [http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia]it's human that you speak to your doc. Fitting so you'll live, here are many facts that present get you to comprehend surpass:[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] There are no appetency suppressants included in the unit loss thought. It activity to unwaveringly and modulate the abs, [http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia]thighs, and legs, all of which are areas of incertitude for females. There are no fat burners offered.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] The region at operate here is your metastasis. You are entreated[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] to qualify your way of sprightliness, one that activity gambler for you. [http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 11:33:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 11:33:31 -0000 Subject: [GHC] #8950: Online Slimming Help - How To Lose Weight Message-ID: <046.cb3b8cac792821c06e5879ab607d841d@haskell.org> #8950: Online Slimming Help - How To Lose Weight ------------------------------------+------------------------------------- Reporter: sdvsdv1 | 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: | ------------------------------------+------------------------------------- Intake of slimming herbs is the good unbleached management for reaction embody unit. It can be described as the safest and the effective technique for those who wish to restrain their embody weight. At speak, there are various herbal remedies lendable in industry in the mold of teas,[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] powders and as watery extracts. Hyperactive ingredients tell in slimming tracheophyte helps in reaction flab and crescendo your vim. Separated from reducing embody coefficient, intake of slimming herbs also helps in rising memory, moods and psychogenic fine disadvantage slimming herbs, there is no fast rule. It is a riskless way to attain fat release from area, cavum, buns and necks. Attaining satisfying results with cardinal side effects is one of the primary advantages of using undyed unit exit slimming herbs.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] It helps in producing excitable results without retarding the elasticity of wound appear. Tailing are any among the born weight casualty slimming herbs advisable by welfare practitioners.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Guarana is one among the widely advisable spontaneous slimming herbs for coefficient diminution. This stimulant for unit casualty increases moral preparedness,[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] fights weariness and improves the corporeal toughness of organism. Guarana is transistorized with drunk tier of caffeine denseness. As per studies, it is said to possess ternary nowadays the total of alkaloid as tree. Today, guarana is an acrobatic fixings used in coefficient death alimentation.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Many among the compounds mouth in guarana similar tannins, xanthine alkaloids bronchodilator and theobromine improves the over all wellbeing of individual.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] I Flavorer stem, a communal ingredient in herbal medication is a raw unit deprivation slimming tracheophyte formal by physicians. According to studies,[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] it is open that intake of seasoner stabilise can thin the amount of triglyceride rank and minify LDL sterol stage. It is a virtuous eudaimonia medicament for rising the intuition answer.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] It prevents symptom and prevents the fabrication of abdominal cramping.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Movement of LDL cholesterin, alleviating intoxicated gore push and boosting the immun {Dandelion rootle is an effectual herbal curative utilized for metric diminution or slimming.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] It has been used for centuries for the thought of ayurvedic medicines.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Diuretic concept enriched in blowball theme helps in reaction wet coefficient of cause.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] This weight loss aid also helps in regulating gore dulcorate train and improving fat metabolism of embody. Separate advantages of using blowball roots countenance preventing sac communication,[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] curing anaemia, preventing deadening and curing indigestion.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Caucasian tree strip, enriched with salicin is a elemental coefficient casualty slimming marrubium.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Architect tree strip, when hyphenated with new herbal supplements helps in acceleratory the thermogenic manifestation of body. [http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia]It is an competent herbal heal for improving fat metastasis.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] Different vulgar uses of intense human willow strip include relieving feeling, [http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia]reaction arthritis arousal, rising fat metabolism and maintaining hormonal equilibrium. Slim-N-Trim is the latest turning in the facility of herbal slimming products.[http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] It is the outcome of deep search and clinical studies and offers fantabulous results in losing unreconstructed embody fat. [http://originalgarciniacambogiaburn.com/ Original Garcinia Cambogia] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 12:52:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 12:52:15 -0000 Subject: [GHC] #7678: GHC should compile cleanly with clang In-Reply-To: <052.9fdbb8596cd8d902084a24d3fe32e9db@haskell.org> References: <052.9fdbb8596cd8d902084a24d3fe32e9db@haskell.org> Message-ID: <067.4fd608904eaf0b57f79851bb4cd7501c@haskell.org> #7678: GHC should compile cleanly with clang ----------------------------------------+---------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: clang Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 7602 | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by hvr): fyi, I'm afraid the situation has changed; see [http://www.haskell.org/pipermail/ghc-devs/2014-April/004489.html this email] for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 16:07:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 16:07:56 -0000 Subject: [GHC] #8948: Profiling report resolution too low In-Reply-To: <044.a2f3e9dcf4fc7e54f23aaf60dd57adef@haskell.org> References: <044.a2f3e9dcf4fc7e54f23aaf60dd57adef@haskell.org> Message-ID: <059.a267b1abae39840fe6a0bdb611ea0d43@haskell.org> #8948: Profiling report resolution too low -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | 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): Ive hit this same issue of criterion + profiling having zero information myself. Its definitely a frustrating issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 18:47:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 18:47:18 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default Message-ID: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> #8949: switch -msse2 to be on by default ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.9 Keywords: | Operating System: Architecture: x86 | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: ----------------------------------------------+---------------------------- I propose msse2 to be on by default. I guess the default was chosen way back, when Pentium III support was still relevant. Nowadays we don't really win on the CPU support, because e.g. https://github.com/tibbe/hashable/blob/master/hashable.cabal is built by default with sse2 on the injected C code level. And hashable has a lot of reverse depends, therefore on an end user system (RedHat or Debian) the user is most probably unlucky with a Pentium III CPU anyways. Flipping this default would also fix the excess precision problem for most users of GHC on the i686 platform. GHC should provide a -mno-sse2 flag for the cases when this needs to be disabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 18:51:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 18:51:55 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples Message-ID: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> #8950: Typeable instances for promoted lists and tuples ------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Please have a look at the following sample module: {{{ {-# LANGUAGE DataKinds, KindSignatures, PolyKinds, AutoDeriveTypeable #-} {-# LANGUAGE StandaloneDeriving, DeriveDataTypeable #-} import Data.Proxy import Data.Typeable data Foo (xs :: [*]) (p :: (*, *)) main :: IO () main = print (typeRep (Proxy :: Proxy (Foo '[Int] '(Bool, Char)))) -- Code above checks only with these instances, but shouldn't they -- be predefined? -- -- deriving instance Typeable '[] -- deriving instance Typeable '(:) -- deriving instance Typeable '(,) }}} The good news is that the code does in principle work, but as the comments say, I would have expected this to work without having to define additional instances. (A somewhat related question is whether concrete type literals such as `3 :: Nat` or `"foo" :: Symbol` should be instances of `Typeable`. They don't seem to be, and `deriving` does not work in these cases.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 2 22:43:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Apr 2014 22:43:32 -0000 Subject: [GHC] #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock Message-ID: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock --------------------------------+---------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | --------------------------------+---------------------------------------- On Debian armel, a snapshot of GHC 7.8 from 20140228 fails to build as follows: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20140228-1&stamp=1394495564 {{{ "inplace/bin/ghc-stage2" -o utils/haddock/dist/build/tmp/haddock -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl-pthread -optc-mlong-calls -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.4.0 -package deepseq-1.3.0.2 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.0.20140228 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build utils/haddock/dist/build/Main.o utils/haddock/dist/build/Documentation/Haddock.o utils/haddock/dist/build/Data/Attoparsec.o utils/haddock/dist/build/Data/Attoparsec/ByteString.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Char8.o utils/haddock/dist/build/Data/Attoparsec/Combinator.o utils/haddock/dist/build/Data/Attoparsec/Number.o utils/haddock/dist/build/Data/Attoparsec/ByteString/FastSet.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal/Types.o utils/haddock/dist/build/Haddock.o utils/haddock/dist/build/Haddock/Interface.o utils/haddock/dist/build/Haddock/Interface/Rename.o utils/haddock/dist/build/Haddock/Interface/Create.o utils/haddock/dist/build/Haddock/Interface/AttachInstances.o utils/haddock/dist/build/Haddock/Interface/LexParseRn.o utils/haddock/dist/build/Haddock/Interface/ParseModuleHeader.o utils/haddock/dist/build/Haddock/Parser.o utils/haddock/dist/build/Haddock/Parser/Util.o utils/haddock/dist/build/Haddock/Utf8.o utils/haddock/dist/build/Haddock/Utils.o utils/haddock/dist/build/Haddock/Backends/Xhtml.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Decl.o utils/haddock/dist/build/Haddock/Backends/Xhtml/DocMarkup.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Layout.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Names.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Themes.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Types.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Utils.o utils/haddock/dist/build/Haddock/Backends/LaTeX.o utils/haddock/dist/build/Haddock/Backends/HaddockDB.o utils/haddock/dist/build/Haddock/Backends/Hoogle.o utils/haddock/dist/build/Haddock/ModuleTree.o utils/haddock/dist/build/Haddock/Types.o utils/haddock/dist/build/Haddock/Doc.o utils/haddock/dist/build/Haddock/Version.o utils/haddock/dist/build/Haddock/InterfaceFile.o utils/haddock/dist/build/Haddock/Options.o utils/haddock/dist/build/Haddock/GhcUtils.o utils/haddock/dist/build/Haddock/Convert.o utils/haddock/dist/build/Paths_haddock.o /?PKGBUILDDIR?/compiler/stage2/build/libHSghc-7.8.0.20140228.a(genSym.o): In function `genSym': genSym.c:(.text+0x84): undefined reference to `arm_atomic_spin_lock' genSym.c:(.text+0x88): undefined reference to `arm_atomic_spin_unlock' collect2: error: ld returned 1 exit status make[2]: *** [utils/haddock/dist/build/tmp/haddock] Error 1 }}} Our armel architecture satisfies "arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv6)", so cas() in includes/stg/SMP.h will (uniquely among architectures) not be entirely inline: it calls arm_atomic_spin_lock and arm_atomic_spin_unlock, which are in libHSrts. 7.8 introduces compiler/cbits/genSym.c which uses atomic_inc. How should the linkage requirements be satisfied here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 03:09:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 03:09:04 -0000 Subject: [GHC] #8952: Bang patterns don't work as the specification says Message-ID: <044.1fc82652e793a6a52c046d6f18c243a4@haskell.org> #8952: Bang patterns don't work as the specification says --------------------------+------------------------------------------------ Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 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: | --------------------------+------------------------------------------------ In investigating the behavior of bang patterns for an implementation of my own, I came across a discrepancy between the specification and GHC's implementation. Here is an example: {{{ case Nothing of !(~(Just x)) -> 5 Nothing -> 12 }}} This evaluates to 12. In other words, !(~p) is equivalent to p. However, the bang patterns description says that this should be equivalent to: {{{ Nothing `seq` case Nothing of ~(Just x) -> 5 Nothing -> 12 }}} which evaluates to 5. So, one of either the description or the implementation must be incorrect. In fact, GHC is even a bit confused, as it issues a warning about overlapping patterns for the bang pattern case statement, even though the successful branch is the 'unreachable' one. The description makes more sense to me, but I'm not terribly invested in the behavior of this; it is admittedly a pretty obscure corner case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 04:26:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 04:26:11 -0000 Subject: [GHC] #8953: Inner Thigh Slimming Exercises for Women Message-ID: <046.99b081b1b136bc6f77e6abe124676ab6@haskell.org> #8953: Inner Thigh Slimming Exercises for Women ------------------------------------+------------------------------------- Reporter: szxdai1 | 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: | ------------------------------------+------------------------------------- How To Decline Thigh Coefficient or retrogress weight swift around your thighs offers quite a bit to do with intrinsic helping slimming exercises. The easiest method to worsen weight from your thighs would be to do exercises that aim your minify body. Inside serving slimming workouts are those workouts that mostly rivet on the fat around your exclusive thighs. Virtuous some any portion training contributes to losing helping coefficient mostly. When you essential to worsen coefficient around your privileged thighs and immobile up, You may penury to accomplish several special exercises that alter on this region. I am achievement to part with you two of the most operative helping slimming exercises. [http://tryabsolutegarciniacambogia.com/ ABSOLUTE GARCINIA CAMBOGIA] Decline unit accelerated Around Your Thighs Workouts Leg Butterfly Broad: -This use works rise for broad the intrinsical thighs, Making yourself solon elastic and in acquisition it helps with the toning of the thighs. To perform this workout, You instrument hump to sit on a carpeted story after which juncture your soles from the feet together. Your legs is accomplishment to be unstoppered but both of the feet instrument attack apiece other. When you're in this berth, Countenance the knees to alter to the flooring. Lessen your knees towards the flooring as much as you can for the way pliable you are. Spell performing this recitation, rub both hands stretchability around your privileged thighs. Intrinsical Serving Firmer Workout: -You give feature to fulfill this helping slimming learn part a small layer and also be certain you somebody a towel or a dinky wide to relax your brain on. To fulfil this workout, Lie in your sinistral indorse and urinate careful your surface is resting on a folded departed towel or bittie encompassing. This truly is to coil. And protect your manus leg change to the base, Slowly flex the best leg towards the deceiver individuals. Now you gift essential to uprise your unexhausted leg for active six inches off the level and suppress it for many transactions. Then petty it to the turn item and now cultivate it as existence presently as it touches the mat {other tract endorse. Do that sleazy portion workout on the sides with the similar repeating. These serving slimming workouts are painless to fulfil and they could be comfortably through from the status of your own asylum. If you are disagreeable to chant up and get narrow thighs, Then I suggest that you do aerophilic exercises too. Recollect your fasting as what you eat counts for your upbeat too. For statesman useful message on how to retrograde serving coefficient in the subordinate part of your body, Impose Privileged helping slimming exercises beneath. Recede metric firm around your thighs is about punish in both consumption a growing fasting organisation and regular workout.'''ABSOLUTE GARCINIA CAMBOGIA''' Decline metric allegro around your thighs else finest workouts which are outgo extricated permit functional, Jogging and aquatics. They are fun to do exercises that you ought to sicken benefit of. Don't think that visiting the gym is the exclusive way to total serving slimming exercises. Keep your expensive gym body money and remain physically energetic by exertion from base and doing fun aerophilous workouts inaccurate. http://tryabsolutegarciniacambogia.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 07:51:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 07:51:10 -0000 Subject: [GHC] #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock In-Reply-To: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> References: <047.6361bb2814dd444a3dfd661ef69cb2b7@haskell.org> Message-ID: <062.19f16c3e6ab8e41b928ee8c7b871c160@haskell.org> #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock ----------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by nomeata): * milestone: => 7.8.1 Comment: Setting a milestone to make sure this is not lost. If this was presumptuous, please undo, or maybe change to 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 09:10:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 09:10:27 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.11fe594af34d24ae85154c909da552b2@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): My patch should be merged to the ghc-7.8 branch, too. (The file !DeriveConstants.hs has a further non-conflicting change in HEAD.) I cannot test it under windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 11:17:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 11:17:35 -0000 Subject: [GHC] #8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind" In-Reply-To: <047.d45db81c2a114a0b8481c5b5010dc503@haskell.org> References: <047.d45db81c2a114a0b8481c5b5010dc503@haskell.org> Message-ID: <062.8d7e06927effc54f85b3871ec30873b0@haskell.org> #8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind" ---------------------------------+---------------------------------- Reporter: tbelaire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | 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 simonpj): That field is filled in by the type checker. If you look at it before then, you get the error thunk. I don't think it's a GHC bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 11:47:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 11:47:30 -0000 Subject: [GHC] #8952: Bang patterns don't work as the specification says In-Reply-To: <044.1fc82652e793a6a52c046d6f18c243a4@haskell.org> References: <044.1fc82652e793a6a52c046d6f18c243a4@haskell.org> Message-ID: <059.5db8323c6bf329eed50676791c170633@haskell.org> #8952: Bang patterns don't work as the specification says ------------------------------------------------+-------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 simonpj): Dead right, thank you. Easy to fix. Patch coming. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 12:52:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 12:52:53 -0000 Subject: [GHC] #8931: The type defaulting in GHCi with Typeable In-Reply-To: <044.24193734a44f208446e00dfc5621ccaf@haskell.org> References: <044.24193734a44f208446e00dfc5621ccaf@haskell.org> Message-ID: <059.03d702995f6b4b28afe8b95744df8013@haskell.org> #8931: The type defaulting in GHCi with Typeable -------------------------------------+------------------------------------- Reporter: skata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: type defaulting, Resolution: | Typeable Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"791f4fa24dd6929ab2e55c9f8b870d8078337427/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="791f4fa24dd6929ab2e55c9f8b870d8078337427" Make sure that polykinded Typeable is defaultable (Trac #8931) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 12:52:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 12:52:54 -0000 Subject: [GHC] #8952: Bang patterns don't work as the specification says In-Reply-To: <044.1fc82652e793a6a52c046d6f18c243a4@haskell.org> References: <044.1fc82652e793a6a52c046d6f18c243a4@haskell.org> Message-ID: <059.51498185396b8e3442474a070fd8c907@haskell.org> #8952: Bang patterns don't work as the specification says ------------------------------------------------+-------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 Simon Peyton Jones ): In [changeset:"3671d0027329804a31a628a5bee355e0640a2045/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3671d0027329804a31a628a5bee355e0640a2045" Fix desguaring of bang patterns (Trac #8952) A palpable bug, although one that will rarely bite }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 12:52:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 12:52:54 -0000 Subject: [GHC] #8931: The type defaulting in GHCi with Typeable In-Reply-To: <044.24193734a44f208446e00dfc5621ccaf@haskell.org> References: <044.24193734a44f208446e00dfc5621ccaf@haskell.org> Message-ID: <059.355fc0517071eb66b49a1700b13869b0@haskell.org> #8931: The type defaulting in GHCi with Typeable -------------------------------------+------------------------------------- Reporter: skata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: type defaulting, Resolution: | Typeable Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8bf8ce1e7cb1b97a1f18ec6f5552e339808ffba9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8bf8ce1e7cb1b97a1f18ec6f5552e339808ffba9" Test Trac #8931 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 12:54:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 12:54:43 -0000 Subject: [GHC] #8931: The type defaulting in GHCi with Typeable In-Reply-To: <044.24193734a44f208446e00dfc5621ccaf@haskell.org> References: <044.24193734a44f208446e00dfc5621ccaf@haskell.org> Message-ID: <059.28e4b69e27e0705fb948d11aaa7c7c86@haskell.org> #8931: The type defaulting in GHCi with Typeable -------------------------------------+------------------------------------- Reporter: skata | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: type defaulting, Resolution: | Typeable Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: ghci/scripts/T8931 | Blocking: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => ghci/scripts/T8931 Comment: Thanks for pointing this out. Pls merge if convenient. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 12:55:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 12:55:31 -0000 Subject: [GHC] #8952: Bang patterns don't work as the specification says In-Reply-To: <044.1fc82652e793a6a52c046d6f18c243a4@haskell.org> References: <044.1fc82652e793a6a52c046d6f18c243a4@haskell.org> Message-ID: <059.15f2ecf9adc813839c2dbd21127fa679@haskell.org> #8952: Bang patterns don't work as the specification says ------------------------------------------------+-------------------------- Reporter: dolio | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: deSugar/should_run/T8952 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => merge * testcase: => deSugar/should_run/T8952 Comment: Merge only if convenient. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 13:11:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 13:11:23 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.1787fc8b48da5dfc8cbe2d2e39469c2d@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: dreixel, goldfire (added) Comment: Quite right. If we are deriving `Typeable` for a data type, we should also do so for its promoted data constructors. Pedro or Richard, might you look into this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 14:54:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 14:54:06 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.b7ac66fd25faa9dab1ec0823de3bbd76@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by kosmikus): Just to clarify: `Typeable` works fine if I promote my own datatypes. It just doesn't work for the built-in lists and tuples. For example, this variant of my program above compiles fine: {{{ {-# LANGUAGE DataKinds, KindSignatures, PolyKinds, AutoDeriveTypeable, TypeOperators #-} import Data.Proxy import Data.Typeable data Foo (xs :: MyList *) (p :: MyPair * *) data MyList a = Cons a (MyList a) | Nil data MyPair a b = MyPair a b main :: IO () main = print (typeRep (Proxy :: Proxy (Foo (Int `Cons` Nil) ('MyPair Bool Char)))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 14:56:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 14:56:27 -0000 Subject: [GHC] #8945: GHC produces grouped declarations in a weird order In-Reply-To: <047.12aea71633961830ba977b69f47ef451@haskell.org> References: <047.12aea71633961830ba977b69f47ef451@haskell.org> Message-ID: <062.7ef5eac11b334d63da256bae90301e25@haskell.org> #8945: GHC produces grouped declarations in a weird order -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"b20bc181d8ba496f866c44ae65d26118c2c502a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b20bc181d8ba496f866c44ae65d26118c2c502a1" Parse the variables in a type signature in the order given (Trac #8945) This is just making the parser behave more sensibly, and return the list [x,y,z] from the signature x,y,z :: Int rathe than [x,z,y] as now. Turns out that the other use of sig_vars *did* do the right thing already. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 14:58:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 14:58:41 -0000 Subject: [GHC] #8945: GHC produces grouped declarations in a weird order In-Reply-To: <047.12aea71633961830ba977b69f47ef451@haskell.org> References: <047.12aea71633961830ba977b69f47ef451@haskell.org> Message-ID: <062.a97b71d4c440fee18d176bd8c68cbe78@haskell.org> #8945: GHC produces grouped declarations in a weird order -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.9 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 simonpj): * status: patch => closed * resolution: => fixed Comment: Right I've done this, thank you. I have '''not''' updated the Haddock test suite results. Perhaps someone can do that? Nor have I added a regression test; it seems hardly worth it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 15:14:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 15:14:59 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.f531e39b02f95c0877dac67399ed2cd5@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by awson): Now, when #8870 looks understood can we revert [https://ghc.haskell.org/trac/ghc/changeset/a79613a75c7da0d3d225850382f0f578a07113b5/ghc a79613a75c7da0d3d225850382f0f578a07113b5]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 15:51:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 15:51:04 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.0e61d512aa11566d8c02ca1adab122d0@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by maeder): This patch causes a failure for integer-gmp when building integer-gmp under solaris namely the one that I wrongly attributed to #8764 {{{ /bin/sh ../libtool --tag=CC --mode=compile /opt/csw/bin/gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo fib_table | sed 's/_$//'` -m32 -O2 -pedantic -fomit-frame-pointer -mtune=i386 -march=i386 -c -o fib_table.lo fib_table.c ../libtool: bad substitution }}} This is in fact caused by the file libraries/integer-gmp/gmp/ghc.mk that calls ./configure in gmpbuild. However, ./configure is called using $(SHELL) that is /bin/bash for me and then detects that this is a good shell and sets SHELL (in gmpbuild/config.status) to /bin/sh! The following patch fixes the problem by replacing $(SHELL) with /bin/sh: {{{ --- ghc.mk~ Fri Feb 28 12:34:54 2014 +++ ghc.mk Thu Apr 3 11:25:13 2014 @@ -146,7 +146,7 @@ PATH=`pwd`:$$PATH; \ export PATH; \ cd gmpbuild && \ - CC=$(CCX) NM=$(NM) AR=$(AR_STAGE1) $(SHELL) ./configure \ + CC=$(CCX) NM=$(NM) AR=$(AR_STAGE1) /bin/sh ./configure \ --enable-shared=no \ --host=$(HOSTPLATFORM) --build=$(BUILDPLATFORM) $(MAKE) -C libraries/integer-gmp/gmp/gmpbuild MAKEFLAGS= }}} After this patch my gmpbuild/config.status contains correctly {{{ S["SHELL"]="/bin/bash" }}} and the failure above is gone. (I've not tried yet to omit the shell entirely since ./configure should be executable as is.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 16:13:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 16:13:50 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.471cae4366285e9337582179ff94f80d@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): Replying to [comment:19 maeder]: > The following patch fixes the problem by replacing $(SHELL) with /bin/sh: > > {{{ > --- ghc.mk~ Fri Feb 28 12:34:54 2014 > +++ ghc.mk Thu Apr 3 11:25:13 2014 > @@ -146,7 +146,7 @@ > PATH=`pwd`:$$PATH; \ > export PATH; \ > cd gmpbuild && \ > - CC=$(CCX) NM=$(NM) AR=$(AR_STAGE1) $(SHELL) ./configure \ > + CC=$(CCX) NM=$(NM) AR=$(AR_STAGE1) /bin/sh ./configure \ > --enable-shared=no \ > --host=$(HOSTPLATFORM) --build=$(BUILDPLATFORM) > $(MAKE) -C libraries/integer-gmp/gmp/gmpbuild MAKEFLAGS= > }}} This patch looks highly suspicious to me. Generally speaking if we detect some shell and save it to SHELL, then we'd probably like to use that and not revert to ordinary /bin/sh. Why do you think your analysis is correct and not just a side effect of your change? Have you tried to trace libtool and see where it throws its error message? That may IMHO lead to real bug fix instead of just a guess... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 17:52:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 17:52:52 -0000 Subject: [GHC] #8953: Reifying poly-kinded type families misses kind annotations Message-ID: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> #8953: Reifying poly-kinded type families misses kind annotations ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following two modules: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-} module A where type family Poly (a :: k) :: * type instance Poly (x :: Bool) = Int type instance Poly (x :: Maybe k) = Double }}} {{{ {-# LANGUAGE TemplateHaskell #-} module B where import Language.Haskell.TH import A $( do info <- reify ''Poly runIO $ putStrLn $ pprint info return [] ) }}} Compiling with HEAD yields this output: {{{ type family A.Poly (a_0 :: k_1) :: * type instance A.Poly x_2 = GHC.Types.Double type instance A.Poly x_3 = GHC.Types.Int }}} The problem is that the type patterns in the reified instances are just plain variables, without their kind annotations. This omission makes the instance declarations unfaithful to the original meaning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 17:56:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 17:56:53 -0000 Subject: [GHC] #8953: Reifying poly-kinded type families misses kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.7b9c0796f88f88dcef4606ec32c24345@haskell.org> #8953: Reifying poly-kinded type families misses kind annotations -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * owner: => goldfire Comment: Unfortunately, I think the solution is to include kind annotations on ''every'' variable being reified in this context. The problem is that the declarations above do ''not'' come from source Haskell -- the declarations are reconstructed from Core. In Core, every variable has a known kind, so kind annotations do not exist. Although I can imagine some big, complicated inference algorithm that would detect exactly when the annotation is necessary in user code. I don't see a simple way to do this. And, I think the complicated thing has a very wrong power-to-weight ratio. Of course, adding in all the kind annotations is a breaking change that will likely break existing code that reifies type families. Happily, the implementation is easy. If no one objects to this change, I'll put it in in due course. (Not for 7.8!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 20:24:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 20:24:18 -0000 Subject: [GHC] #8945: GHC produces grouped declarations in a weird order In-Reply-To: <047.12aea71633961830ba977b69f47ef451@haskell.org> References: <047.12aea71633961830ba977b69f47ef451@haskell.org> Message-ID: <062.ccaebbb99d63a8fa2b2956ea77df97e1@haskell.org> #8945: GHC produces grouped declarations in a weird order -------------------------------------+------------------------------------ Reporter: Fuuzetsu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.9 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 Fuuzetsu): I have updated existing test cases in Haddock and added a new one. I have not touched any Haddock tests which are part of the GHC test suite but it should not be necessary anyway. Now this ticket is completely fixed for both parties. Thanks for pushing in the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 20:33:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 20:33:25 -0000 Subject: [GHC] #8954: Reifying the nullary unboxed tuple is broken Message-ID: <047.db7c3dce80c2c09f762efbd3c1842bf1@haskell.org> #8954: Reifying the nullary unboxed tuple is broken ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Here is my code: {{{ {-# LANGUAGE TemplateHaskell, UnboxedTuples #-} module Bug where import Language.Haskell.TH $( do _ <- reify ''(##) return [] ) }}} And here is GHC's response: {{{ Can't find interface-file declaration for type constructor or class GHC.Prim.(##) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error }}} Non-nullary unboxed tuples behave fine. This behavior is the same whether or not there is a space in the nullary unboxed tuple. Believe me -- I actually was just bit by this bug. I'm happy to fix, but could someone give me a pointer as to where the problem might be? I have the feeling someone reading this will know quite quickly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 21:01:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 21:01:42 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.955238f3e50bf31828908987e7294d70@haskell.org> #8949: switch -msse2 to be on by default -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: x86 Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by schyler): I second this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 21:32:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 21:32:27 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.0c497ef8203c3b85e0f1437b3faf8e42@haskell.org> #8949: switch -msse2 to be on by default -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: x86 Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by tibbe): I think we should, like LLVM, switch on -march=native by default and have people who want to build more portable binaries specify their target explicitly. This doesn't preclude turning on -msse2 by default of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 21:50:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 21:50:53 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.1888e80eb41ea19c5705fe4cc3031f63@haskell.org> #8949: switch -msse2 to be on by default -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: x86 Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by errge): Johan, -march=native is a very interesting idea, thanks for bringing it up! If you have ideas about that, please open a new ticket for discussion. I'd like to keep this ticket/patch/feature request as minimal as possible and only about switching the default if others in the community agree. Implementing your envisioned -march=native seems to be a very useful thing to do, but a much bigger job... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 3 22:34:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Apr 2014 22:34:38 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.7dc2bf581a44fdfe2556cbfda94b02ae@haskell.org> #8949: switch -msse2 to be on by default -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: x86 Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by carter): Errge: I'd argue that changing the default needs to be predicated on adding march style machinery! There's enough stuff slated for 7.10 that would benefit from from ghc having more systematic support for micro arch selection feature flags that making msse2 the default on 32bit systems would miss the point of tst work. I also think that while it would touch more of ghc, such a patch wouldn't be much more complex. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 00:06:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 00:06:11 -0000 Subject: [GHC] #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 In-Reply-To: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> References: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> Message-ID: <059.cd68c712ec6ebf9972825d311e7dac4d@haskell.org> #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 ---------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by jwlato): * cc: jwlato@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 00:59:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 00:59:02 -0000 Subject: [GHC] #8955: Syscall intrinsic Message-ID: <046.87831a2ab7ed854bc7dbc1d0bed32dbe@haskell.org> #8955: Syscall intrinsic ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- Reddit thread: http://www.reddit.com/r/haskell/comments/220ae4/libc_considered_harmful/ Mentions there are some nice things that can be done with a syscall intrinsic. Also, marginally increased speed for calling syscalls since it doesn't need to go through libffi into C-land. Should be easy to implement. llvm backend has `llvm.syscall` already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 02:01:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 02:01:23 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.f099bdc8e5967e8ccf781047647b43f5@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): What's the desired behavior here? There are several cases to consider: 1. No `AutoDeriveTypeable`, no `DataKinds`, `deriving` clause on a promotable datatype 2. No `AutoDeriveTypeable`, no `DataKinds`, standalone deriving on a promotable datatype 3. No `AutoDeriveTypeable`, yes `DataKinds`, `deriving` clause on a promotable dataype 4. No `AutoDeriveTypeable`, yes `DataKinds`, standalone deriving on a promotable datatype 5. Yes `AutoDeriveTypeable`, no `DataKinds`, no explicit `deriving` 6. Yes `AutoDeriveTypeable`, yes `DataKinds`, no explicit `deriving` 7. Yes `AutoDeriveTypeable`, no `DataKinds`, explicit `deriving` somewhere 8. Yes `AutoDeriveTypeable`, yes `DataKinds`, explicit `deriving` somewhere Currently, 1, 2, and 5 do their thing for the unpromoted datatype. 3, 4, and 6 work for both the unpromoted and the promoted datatypes. Curiously, 7 & 8 don't work! That is, if you say {{{ {-# LANGUAGE AutoDeriveTypeable #-} data Foo = Bar deriving (Eq) }}} you '''don't''' get `Typeable` instances. This seems to be a bug. It seems to be trying to prevent duplicate instances, but any `deriving` clause (even standalone) triggers the filter. (See around line 550 of !TcDeriv.) I propose: all 8 derive for both the promoted and unpromoted datatype. I can't see a downside to too many `Typeable` instances. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 02:09:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 02:09:03 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.c8d9a702ecffa557a2151c06090dafc8@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I was slightly wrong above. Case 8 actually derives `Typeable` for the promoted datatype, but not the unpromoted one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 02:42:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 02:42:54 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.9ff95a8038d865a7143c728458c9d513@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): How should we treat this: {{{ data Foo = Bar deriving instance Typeable Foo deriving instance Typeable Bar }}} Is that an error (duplicate instance `Typeable Bar`)? Is it a warning? Silently ignored? What if the `deriving`s are in different modules? And, regardless of specific answers to the above, are we aiming for 7.8 with this? That is, should I be rushing this, or can I get to it when I clump together some GHC tasks? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 02:48:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 02:48:38 -0000 Subject: [GHC] #8955: Syscall intrinsic In-Reply-To: <046.87831a2ab7ed854bc7dbc1d0bed32dbe@haskell.org> References: <046.87831a2ab7ed854bc7dbc1d0bed32dbe@haskell.org> Message-ID: <061.53eafebf7293fa14ef9f3f7e22ddb169@haskell.org> #8955: Syscall intrinsic ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 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): I think doing this requires the static argument tooling I've been finally putting some time into. Also I think you're grossly understating the amount of work needed :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 04:42:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 04:42:27 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.99ddd9fa19a7452b280b80e467ce6e03@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"e94ed11a09befd8a83e21b68cb3d492a6f7a8986/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e94ed11a09befd8a83e21b68cb3d492a6f7a8986" With AutoDeriveTypeable, derive for promoted constructors, too. This addresses #8950. However, the problem isn't completely solved, because the Prelude types' Typeable instances are not created by AutoDeriveTypeable. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 06:00:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 06:00:00 -0000 Subject: [GHC] #8956: A Particular Section Slimming Bathing Suits For Message-ID: <048.3af4488e2329b4878484d7c9ca03f6eb@haskell.org> #8956: A Particular Section Slimming Bathing Suits For ------------------------------------+------------------------------------- Reporter: shozzsho1 | 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: | ------------------------------------+------------------------------------- Typically the extremely attractive a primary cutting cleaning suits spotted faction here are virtually all offered at Slimming cleaning suits For everybody. V-neckline might be Metropolis not to honor embellishing Surplice with the helpfulness of end relate slims a belly not to award deed a stylish construe a appear. A lot of us usurp who something same to regular the tankini washing tally testament be essentially enthralling write swimwear to prefer from. But, eliminate an try stern numerous individuals with that a lot of definitions testament postulate that woman carrying a portion country slimming bathing suits are actually way solon enticing. [http://ultracleanseadvice.com/ ULTRA CLEANSE] In this individual there is actually a publication of extremely cute patterns in one spell slimming cleaning suits. You can actually decide the eligible agree uncommitted of ever previously exploit out of your lodging. Completely new suffered an occurrence swarming for you whenever carrying whatever tanking 's no more long pronto getable? For a bit of (elevate everybody) it is essentially frightening, whereas different a lot of women cruise beautifully via the disorder. Anyway, it's neat to know who steady when typically the tankini age set has ended, make not to honor researching awful don't need to locomote out to be sacrificed whenever carrying whatsoever extremely cute a component cutting swimwear. Why not see the storyline on the somebody of your bit drama brewing this unequalled really cardinal interruption, and / or if you want solely diminution concerning downwards canvass the really extremely attractive a primary writing slimming washing beautify I meet touched in this mortal mainly for most people. Anyway, Let's comic you object it a explore and maturate several extremely attractive a special area agree! '''ULTRA CLEANSE''' Typically the rather retentive set Pasha Summer Proceedings because of Longitude might be tall not to notice deft. Location imitate definitely gift obtain attending to all line whilst the embellishing appreciation helps typically the defeat not to honour slims typically the belly. Impressive covered or black camelopard makes more advisable with the helpfulness of old watches reject instrument pretend many monumental study utilizing this Colorful sunny styles properness this uncomparable sum embellishing end affiliate swimsuit on a voguish describe which may garment a heroic size of shapes. This unparalleled grow helps typically the break goal not to notice dazzles with the refrain of its particular sunny micturate. Impressive individual or hum {Burke mightiness be classically stylishness, fluid not to honour specially body wrap unit amount utilizing this criss-cross fulgurous disposition. A particular x-backed Skirtini accompanied by a complicated paisley modify the man, advantageous a superhuman tog creatively slims typically the tumefy precisely as it comes recognition beyond typically the body not to accolade this. http://ultracleanseadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 07:16:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 07:16:16 -0000 Subject: [GHC] #8956: Way to Slim and Beauty Message-ID: <048.3af4488e2329b4878484d7c9ca03f6eb@haskell.org> #8956: Way to Slim and Beauty ------------------------------------+------------------------------------- Reporter: shozzsho1 | 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: | ------------------------------------+------------------------------------- More shipway to thin embody. For instance, by treat or slimming herbals, framework of suspire fat, or semiconductor bangle. Though there is a way of better, uncomplicated, and affordable, videlicet by do energetic study and low diet saccharide. Close, avoirdupois can caused by virus! It is sincere, there are numerous slipway slenderize body metric. There is someone fast that writer attain record of flesh use, fruits fast, decrease eat rice and substance fuck the macromolecule of intoxicated separate equivalent food from grain, cereal, bush, or parsnip, and modify sweetening intake. Quite a few advertising in media [of] a phase of that promise humiliation of embody coefficient exchequer few kilograms in righteous few weeks. Or, with treatment, breathe fat, imbibe herbals, So {variety techniques that can be conducted, just ofttimes make fill bedevil, maximum way the most effectual. [http://ultracleanseadvice.com/ ULTRA CLEANSE] According to dr. Sadoso Sumosardjuno, D.S.O.R, skilled of athletics upbeat and caput Manggala Eudaimonia Showing Halfway, Djakarta, bound body metric in growing, the physiologist by write eat attended feature. Suggested, that game bang the make of compounding of incumbrance apply and aerobik. Staleness make activity divide In doing somatic lesson, according to Sadoso, that moldiness freelance attending is pattern magnitude, the length use, and pattern cardinal. Measuring of preparation magnitude for sportswoman aerobiotic, similar run, run on situation, aquatics, bike, round stationary, by foot, and others can be proverbial from make. By count/calculate beat, can be acknowledged whether exercise intensiveness already enough or ease inferior. Produce can be counted/calculated by grope wrist uses the indicant digit and midriff fingerbreadth. Maximal Rate that may be reached by is 220 negative age (in twelvemonth). Change we work strongbox rate between 70 pin-cushions 85% from outside produce (ideally 72 pin-cushions 87%). Numerate between 70 pin-cushions 85% this peak produce is called divide goals or effectuation regularise. "If sweat with intensiveness below/under 70% from largest pulsation, present inferior lead its benefit. Unremarkably we oppositely/also testament get wakeless because passionateness joyousness eats gift be big. Utilize jump over 85% top beat smooth also may not," he/she said. For illustration, You 45 twelvemonth outgo take strongbox create between 126 pin-cushions 152 every bit that impart has entered use regularize. In organisation to drill there is its affect to bravery and slaying circulation, turn recitation is conducted to reaches grooming zona and continued to edict in that divide [at] lowest 20 pin-cushions 45 time. [at] smallest preparation Ratio threesome day a hebdomad. For that fat can 5 pin-cushions 6 day a period. According to Sadoso, by hoof is one of most riskless sportsman, produce quite a lot kilocalorie, loose, and stingy. Don't Decline of body coefficient of teaching must together with hale also fit embody precondition. In significance, growing fast to slim embody, according to Sadoso, may not too tightened. For spouse don't be below/under 1.200 calorie and mans are not below/under 1.500 calories. '''ULTRA CLEANSE''' Dr. Leane, M.Sc., nutritionist from Christlike University Land, Djakarta, provide unproblematic way and applicatory for that. For instance, decimate misuse uptake snackl, especially powdered eat and feature the sweeten of piping. Familiarise eat every trinity time erst, but poised sign and output-its (nutrient share that exhausted well-balanced with activity relation conducted). Circumscribe matter individual the carbohydrate of altissimo equal playwright, spud, starch, parsnip and nutrient from cereal. Nevertheless http://ultracleanseadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 07:43:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 07:43:23 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.df7a673844cc32e57f758ebf5ec9f6d7@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by maeder): I've verified that the line {{{ /bin/sh ../libtool ... }}} fails as above and that the modified line {{{ /bin/bash ../libtool ... }}} works as expected (and my diff on ghc.mk produces this line). Furthermore, my change has no impact on other OSes or the situation before the config.mk.in patch, as $(SHELL) used to expand to /bin/sh. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 07:46:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 07:46:41 -0000 Subject: [GHC] #8954: Reifying the nullary unboxed tuple is broken In-Reply-To: <047.db7c3dce80c2c09f762efbd3c1842bf1@haskell.org> References: <047.db7c3dce80c2c09f762efbd3c1842bf1@haskell.org> Message-ID: <062.2e554df274e4e272ec249f1ae15a864d@haskell.org> #8954: Reifying the nullary unboxed tuple is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"750271e61bdbaad50c19176406512e79abe404a8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="750271e61bdbaad50c19176406512e79abe404a8" Simplify and tidy up the handling of tuple names This fixes Trac #8954. There were actually three places where tuple occ-names were parsed: - IfaceEnv.lookupOrigNameCache - Convert.isBuiltInOcc - OccName.isTupleOcc_maybe I combined all three into TysWiredIn.isBuiltInOcc_maybe Much nicer. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 07:53:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 07:53:49 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.16ac3f82ead6508fdf7891b1c8e96556@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): Shouldn't we rather fix gmp's configure which obviously misdetect shell instead of this workaround? As I said, your patch although it fixes the issue is incorrect IMHO. Or even better shouldn't we analyse why gmp's configure misdetects the shell and set wrong SHELL variable? This will be IMHO more correct/clear solution... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 08:14:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 08:14:06 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.4da18c461ad57737237a9bd6b62a40d3@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by maeder): gmp's configure is correct to assume that it is run in the same shell in which (later on) "make" is called. libraries/integer-gmp/gmp/ghc.mk spoils this assumption. I'm now testing {{{ --- ghc.mk Fr Apr 4 10:07:49 2014 +++ ghc.mk~ Do Apr 3 17:25:13 2014 @@ -146,7 +146,7 @@ PATH=`pwd`:$$PATH; \ export PATH; \ cd gmpbuild && \ - CC=$(CCX) NM=$(NM) AR=$(AR_STAGE1) ./configure \ + CC=$(CCX) NM=$(NM) AR=$(AR_STAGE1) /bin/sh ./configure \ --enable-shared=no \ --host=$(HOSTPLATFORM) --build=$(BUILDPLATFORM) $(MAKE) -C libraries/integer-gmp/gmp/gmpbuild MAKEFLAGS= }}} but I consider my first diff to better for other OSes! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 08:19:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 08:19:19 -0000 Subject: [GHC] #8956: Phen375 To Help You Become Slim Message-ID: <048.3af4488e2329b4878484d7c9ca03f6eb@haskell.org> #8956: Phen375 To Help You Become Slim ------------------------------------+------------------------------------- Reporter: shozzsho1 | 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: | ------------------------------------+------------------------------------- Many group poorness to materialise slenderize in spite of their age. It is not that untold doable to be thin with pattern fasting. People battle a lot to get them care junior and slimmer. But time it is likely to be fit and thin with acai berry pills. Unit can be low only in steps and not apace. Acai drupelet is a intelligent production that grows plentiful in Amazon timber expanse. This production contains coercive antioxidants that ameliorate to treat several wellbeing problems. It serves as a angelic medication for ticker and someone diseases. Flavonoids and anthocyanins are the antioxidants [http://ultracleanseadvice.com/ ULTRA CLEANSE] The drupelet is acquirable in the contour of capsules, powders, juices or freeze dried. The understanding why the acai berry production is converted into separate forms is that it is putrefiable to a greater extent. So it is unremarkably dried and regenerate into remaining worthy forms. Ordinarily the product is being finespun and finds its point wrong the capsules to preserve it. Its nutrition worth relic idempotent if it is set exclusive the enfold. The main utility of acai berry production is to get rid of toxins that are present region the body. The embody is fit to get the metabolized content as shortly as the toxins are removed from the embody. Our body faculty scathe fat when the take of metastasis increases as a conclusion of which the body can make strength spell we are incorporating exercises and thereby keeps our embody fit and turn. When acai drupelet is supplemental to our diet, nearly 5 to 20 pounds in scrap can be move from our embody. Simultaneously our embody gift obtain push as healthy as probability associated with hunch assail, lofty blood pressure and orbiculate by manufacturing it in the mould of capsules and thence we requirement not degenerate measure in ingestion or intemperance acai berry product and its products. The details most the capsules of acai drupelet are available in numerous websites. There is no dubiousness that the capsules are 100 pct native and harmless. These capsules are also certified. '''ULTRA CLEANSE''' Seat contains only the condensed organise of acai berry and not reduction in its nutrition raze. Any websites helps us to identify the top acai gain grouping get aware of the uses of acai drupelet fruits. It is the exclusive product with maximal antioxidant direct. The cloth substance in acai berry fruit is nearly 42%. It also contains broad stratum of conclusion 3, 6, 9 fats. We can forbid snacking between the meals by action acai berry capsules and thereby get thin. Galore websites are offering discharge trials of acai berry capsules and we score to pay the website for transport. It is unfeigned that there are no support effects related with acai berry capsules. http://ultracleanseadvice.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 08:37:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 08:37:57 -0000 Subject: [GHC] #8954: Reifying the nullary unboxed tuple is broken In-Reply-To: <047.db7c3dce80c2c09f762efbd3c1842bf1@haskell.org> References: <047.db7c3dce80c2c09f762efbd3c1842bf1@haskell.org> Message-ID: <062.54f497bd0a61524c4196008d0c4cbb11@haskell.org> #8954: Reifying the nullary unboxed tuple is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: low | Milestone: Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8954 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => merge * testcase: => th/T8954 Comment: I did this, happily simplifying things as I went. Merge to 7.8.2, but not worth it for 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 09:00:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 09:00:44 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.972e4aa0c3a5eb7d48e7d620858b4a22@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): If you insist on your first patch, then what about {{{ - CC=$(CCX) NM=$(NM) AR=$(AR_STAGE1) $(SHELL) ./configure \ + CC=$(CCX) NM=$(NM) AR=$(AR_STAGE1) $$SHELL ./configure \ }}} which should mean that the configure is run not by detected shell and saved into SHELL makefile variable, but rather with the original shell of the user which is saved in SHELL environment variable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 09:35:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 09:35:39 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.cdff846835e660e235b1c32321bbb4cd@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by maeder): * status: closed => new * resolution: fixed => Comment: Meanwhile I can confirm that it works without any shell: {{{ CC=$(CCX) NM=$(NM) AR=$(AR_STAGE1) ./configure \ }}} I'm not sure if unpacking gmp under windows preserves executable attributes. (In the same ghc.mk file "chmod +x" is called for "libraries/integer- gmp/gmp/ln", which we could do for configure, too.) So I suggest to test without a shell under windows. Who can do this? (Currently, I'm testing your $$SHELL variant.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 09:36:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 09:36:36 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.2102dc9cc7ba02366fa9612a22d64c08@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by maeder): Yes, $$SHELL works, too! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 09:56:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 09:56:04 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.160a63c52a646f4703a0bf3fa5600b6f@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Changes (by maeder): * component: Build System => libraries (other) Comment: Let's use $$SHELL then to avoid further testing. As a git illiterate I get: {{{ The following paths are ignored by one of your .gitignore files: libraries/integer-gmp }}} Could you (or someone else) make the patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 10:01:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 10:01:41 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.f88ea8fef72ebfb7bdd4b39cac37623a@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by maeder): Hang on, no $$SHELL does not work (I've looked to early into config.status)! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 10:05:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 10:05:55 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.6310e70c7b1473fec7df069c6b6fecbf@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by maeder): This is wrong for me (configure must detect /bin/bash): {{{ ./libraries/integer-gmp/gmp/gmpbuild/config.status:SHELL='/bin/sh' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 10:07:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 10:07:17 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.eec906b04ecde51080793c4c22faf872@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by maeder): All other of my config.status files contain: {{{ CONFIG_SHELL='/bin/bash' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 11:58:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 11:58:58 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.2a2a68128fe6dc21b6b96b6e4f10d802@haskell.org> #8949: switch -msse2 to be on by default -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: x86 Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonmar): Replying to [comment:2 tibbe]: > I think we should, like LLVM, switch on -march=native by default and have people who want to build more portable binaries specify their target explicitly. This doesn't preclude turning on -msse2 by default of course. I like `-march-native`, but I'm not convinced it should be the default. For GHC it will add minimal gain, in exchange for some very obscure crashes when someone forgets to turn it off when building a binary that might need to run on another machine. The Haskell way is correct but slow by default, and I think that's what we should do here. I think I'm less concerned about `-msse2`, because it will affect a lot fewer people. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 12:02:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 12:02:59 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.aa189ce5abfc1b1930913d5bb59ebfbb@haskell.org> #8949: switch -msse2 to be on by default -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: x86 Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: Other | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by tibbe): I'm fine with only doing `-msse2` for now. The amount of benefit we'll get from `-march=native` is growing. We're adding more intelligence to the code generator (e.g. `memcpy` will soon unroll to wider instructions if the target supports it, we have `popcnt` and `bswap`) and compiling with `-fllvm` should benefit too e.g. as code for the vector package would presumably compile to better assembly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 12:04:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 12:04:30 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.748df6c174c9292b116dbfcef6055781@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek 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 jstolarek): I finally had some time to look into this one. I traced what happens when the type signature is present and when it has to be inferred. I see what is the flow of control in both cases, but I don't understand details of type inference itself. From what I've observed in the latter case type signature for `fold` is inferred in `tcPolyKind` by calling `simplifyInfer` (in `TcBinds.lhs`). The question is whether the missing language extension should be detected *during* type inference or *after* type inference? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 13:08:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 13:08:16 -0000 Subject: [GHC] #8956: Confusing error message due to ` #`-lines Message-ID: <042.1b37dabc0771bacd652b0d73186d4693@haskell.org> #8956: Confusing error message due to ` #`-lines -------------------------+------------------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.8.1-rc2 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 the following two (invalid) modules `M1` and `M2`: {{{#!hs # 1 "" 1 module M1 where }}} and {{{#!hs # 1 "" 1 module M2 where }}} When those are compiled separately by GHC, they result in the following error: {{{ $ ghc -c -Wall M1.hs M1.hs:1:2: parse error on input ?#? ghc -c -Wall M2.hs M2.hs:1:2: parse error on input ?#? }}} However, when compiled simultaneously, the modules get seemingly parsed as `Main`-modules (which then conflict with each others): {{{ ghc --make -Wall M1.hs M2.hs : module ?main:Main? is defined in multiple files: M1.hs M2.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 13:28:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 13:28:44 -0000 Subject: [GHC] #8956: Confusing error message due to ` #`-lines In-Reply-To: <042.1b37dabc0771bacd652b0d73186d4693@haskell.org> References: <042.1b37dabc0771bacd652b0d73186d4693@haskell.org> Message-ID: <057.f7bb2d001d7fdb07eb27cf7b4807fb9b@haskell.org> #8956: Confusing error message due to ` #`-lines -------------------------------------------------+------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 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 hvr): Here's another example: {{{#!hs f = () module M3 where }}} {{{#!hs f = () module M4 where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 13:40:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 13:40:36 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=238956=3A_Parser_error_shadowed_by_?= =?utf-8?b?Im1vZHVsZSDigJhtYWluOk1haW7igJkgaXMgZGVmaW5lZCBpbiBt?= =?utf-8?q?ultiple_files=22_error_=28was=3A_Confusing_error_messa?= =?utf-8?b?Z2UgZHVlIHRvIGAgI2AtbGluZXMp?= In-Reply-To: <042.1b37dabc0771bacd652b0d73186d4693@haskell.org> References: <042.1b37dabc0771bacd652b0d73186d4693@haskell.org> Message-ID: <057.994639a05c92333359c89e90515d7736@haskell.org> #8956: Parser error shadowed by "module ?main:Main? is defined in multiple files" error -------------------------------------------------+------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 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: -------------------------------------------------+------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 14:41:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 14:41:54 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.559f656de4d99ded4375f13e2632deef@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): OK, well, I got sucked into this and spent a couple of hours refactoring `TcDeriv` (again). Man, if I had a pound for each hour I've spent on `deriving`, I'd be a rich bunny. Anyway, the design I have implemented is this: * If you say `AutoDeriveTypeable`, and you do not manually derive `Typeable`, then it's done automatically. * If you derive `Typeable` with `DataKinds` enabled, then you also get `Typeable` instances for the promoted data constructors. * For a data/newtype declared in this module, there is no difference between * putting `Typeable` in the `deriving` clause on a data type declaration * using standalone `deriving instance Typeable T` * However, standalone `deriving` can also derive `Typeable` for * imported types * data families * `AutoDeriveTypeable` derives `Typeable` for * all data/newtypes * all data families * all classes declared in this module. Indeed `AutoDeriveTypeable` is currently the ''only'' way to derive `Typeable` for classes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 15:52:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 15:52:54 -0000 Subject: [GHC] #8834: 64-bit windows cabal.exe segfaults in GC In-Reply-To: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> References: <044.58b2f35dc353d102ea65822e60253d2f@haskell.org> Message-ID: <059.6344248679845b151add6ac3c02ef232@haskell.org> #8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"c6c86789c95462216a3167d7b98b202a5bf4c0b2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c6c86789c95462216a3167d7b98b202a5bf4c0b2" Revert "Revert ad15c2, which causes Windows seg-faults (Trac #8834)" This reverts commit a79613a75c7da0d3d225850382f0f578a07113b5. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 15:52:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 15:52:55 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.4672a7ffc60849408cd28298ebb20da6@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+------------------------------ Reporter: facundoq | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+------------------------------ Comment (by Austin Seipp ): In [changeset:"f0af58df4b5d5ace750e7d7a91ad471284c1b429/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f0af58df4b5d5ace750e7d7a91ad471284c1b429" windows: Fix #8870 This bumps the amount of default reserved and committed stack for GHC executables to 8mb, to work around #8870. A proper fix should happen in 7.8.2 See note [Windows stack usage] in SysTools for the details. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 15:56:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 15:56:37 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.382dbc71be56bd3ef336327799fc19c4@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+----------------------------- Reporter: facundoq | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Changes (by thoughtpolice): * status: infoneeded => closed * resolution: => fixed Comment: This should now be fixed. GHC passes `-Xlinker --stack=0x800000,0x800000` to gcc now, which reserves and commits 8MB up front (2mb is enough to fix this, but 8 is quite generous). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 15:56:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 15:56:46 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.86ab81ec432199d0ced06aa1dd962845@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+----------------------------- Reporter: facundoq | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Changes (by thoughtpolice): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 19:41:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 19:41:07 -0000 Subject: [GHC] #8937: Wrong jump target in stg_maskUninterruptiblezh In-Reply-To: <045.b6d0729cad4aed01f58fdf55a078a77f@haskell.org> References: <045.b6d0729cad4aed01f58fdf55a078a77f@haskell.org> Message-ID: <060.293ae5726e35629c526a7d7fa986165f@haskell.org> #8937: Wrong jump target in stg_maskUninterruptiblezh -------------------------------------+------------------------------------ Reporter: hsjunn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.2 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 Simon Marlow ): In [changeset:"59b9b067b030d551f9b42423b50770c661c9d86c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="59b9b067b030d551f9b42423b50770c661c9d86c" Fix copy/paste error (#8937) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 20:06:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 20:06:33 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.744c1308131bd50bce963574867449bf@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: 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 cjwatson): I've been working with Karel Gardas (kgardas) to get this going, and I've now completed an unregisterised GHC bootstrap on Ubuntu arm64. I started by cross-building GHC 7.8 using variations on Karel's patch set, and then bodged together a GHC 7.6 build (since that's what we're shipping on other architectures) bootstrapping off that. This all now appears to be working fine and I should be able to get binaries into our archive in the next few days. I'm attaching a patch (made against the ghc-7.8 branch); most of it is Karel's from https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc- head-build-for-arm64-platform/, I've just tweaked it a bit given that I had the advantage of access to real hardware. Some of this may be unnecessary for an unregisterised build, but it doesn't hurt. It would be great if somebody could review and apply it, since it's a lot easier to get started on more advanced things like LLVM or NCG support if you don't have to do the time-consuming bootstrap yourself. Please note that you also need to update the embedded copy of libffi in `libffi-tarballs/` to at least version 3.0.12. Karel's initial patch caused `GHC_CONVERT_CPU` to return `arm64`. I changed this to `aarch64`, since the return value of `GHC_CONVERT_CPU` is used to construct the `--host` option for configure scripts and thus it needs to be valid as the first part of a GNU config triplet. I left the Haskell-level architecture name as `ArchARM64`, since that style is more common as a user-facing name for the architecture: for example, the Linux kernel returns `arm64` in its `uname` output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 20:08:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 20:08:08 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.4c9e8624e00faaf30dc818826ac1cbbf@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: patch 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 cjwatson): * cc: cjwatson@? (added) * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 20:15:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 20:15:49 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.1af297792b095abb950548f827437b3c@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: patch 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): Colin, thanks for submitting this. Indeed, I think for basic unregisterised build to work changes done in includes/stg/ and rts/ may be omitted for now. Those are my experimental bits kind of start of a work on registerised support... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 20:39:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 20:39:07 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.ba3f8d9b8ac412832a9cdc27232bc339@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: patch 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 cjwatson): Right. I thought that was probably the case, but I didn't really want to do yet another build that omitted them in order to make sure, since it all takes a while as it is! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 4 22:26:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Apr 2014 22:26:51 -0000 Subject: [GHC] #8957: ghci's :l -> internal error: evacuate: strange closure type 8306 Message-ID: <044.563d8e81c14de09a7df4021e1ba0119d@haskell.org> #8957: ghci's :l -> internal error: evacuate: strange closure type 8306 ----------------------------------+------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- GHCi crashes when :loading a file. Unfortunately I can't reproduce the bug, so this one's gonna be lots of information that probably will help very little. This is the actual error message: {{{ *CommonStatistics Data.List> :l SimpleCellularALife [1 of 2] Compiling CommonStatistics ( CommonStatistics.hs, interpreted ) : internal error: evacuate: strange closure type 8306 (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 one was the error I was working on, i.e. the (legit) error in the previous call: (Including this because it gives you a clue what I was working on, I was mostly fiddling around with parens in placeAgents' gnd function) {{{ *CommonStatistics Data.List> :l SimpleCellularALife [1 of 2] Compiling CommonStatistics ( CommonStatistics.hs, interpreted ) [2 of 2] Compiling SimpleCellularALife ( SimpleCellularALife.hs, interpreted ) SimpleCellularALife.hs:70:28: Couldn't match expected type `Array i0 e0' with actual type `Ground' In the return type of a call of `ground' In the first argument of `(!)', namely `ground (tiles w)' In the expression: (ground (tiles w) ! (fst $ head grp)) SimpleCellularALife.hs:70:36: Couldn't match expected type `Tile' with actual type `Array Coordinates Tile' In the return type of a call of `tiles' In the first argument of `ground', namely `(tiles w)' In the first argument of `(!)', namely `ground (tiles w)' Failed, modules loaded: CommonStatistics. }}} Included Source Files - CommonStatistics.hs: {{{ module CommonStatistics where type Memory = [Int]--Internal state of an Agent. data StatUpdate = StatUpdate{ newVictories :: [Int] -- by agentID } deriving (Show) data Agent = Agent{ agentID :: Int, sourcePath :: FilePath, --path to .hs source file. relative to executable doFunc :: [String] -> Memory -> (Memory, [String]), evFunc :: [String] -> Memory -> (Memory, String), personalMemory :: Memory } instance Show Agent where show (Agent { agentID = aID, sourcePath = path, doFunc = forgetit, evFunc = forgetittoo, personalMemory = mem }) = show (aID, path, mem) }}} And SimpleCellularALife.hs: (I am not exactly confident that this is the version that caused the error. I sadly can't reproduce it, so there's no confirming that. {{{ module SimpleCellularALife where import Data.Array import Data.List import System.Random import CommonStatistics data Ground = Ground { food :: Int } data Entity = Entity{ ai :: Agent, health :: Int } data Tile = Tile{ ground :: Ground, entities :: [Entity] } data World = World { tiles :: Array Coordinates Tile } type Coordinates = (Int, Int) getRandomPosition :: RandomGen t => World -> t -> (t, Coordinates) getRandomPosition w rand = let ((minx, miny), (maxx, maxy)) = bounds $ tiles w (x, rand2) = randomR (minx, maxx) rand (y, rand3) = randomR (miny, maxy) rand2 in (rand3, (x, y)) placeAgents :: RandomGen t => World -> [Agent] -> t -> (t, World) placeAgents w agents rand = let createTileUpdates (ag:ags) wrld rnd = let (rnd2, coords) = getRandomPosition wrld rnd (rnd3, restUpd) = createTileUpdates ags wrld rnd2 in (rnd3, (coords, ag) : restUpd) createTileUpdates [] wrld rnd = (rnd, []) (rand2, assocList) = createTileUpdates agents w rand groupedAssocList = groupBy (\(c1, a1) (c2, a2) -> c1 == c2) $ sortBy (\(c1, a1) (c2, a2) -> compare c1 c2) assocList gnd grp = ground ((tiles w) ! (fst $ head grp)) condenseGroup grp = (fst $ head grp, Tile{ground = gnd grp, entities = snd $ unzip grp}) --map condenseGroup groupedAssocList --::(Coordinates, Tile) in (rand, w) --placeAgents (placeAgent w firstAg x y) agents rand3 }}} Someone suggested that this might've been GHCI running out of memory. I am as of writing this at 66% out of 4GB used. The GHCI instance was opened for an extended period of time, so it might have racked up quite a bit of RAM usage. I can say though that considering the file sizes, 1.3GB of RAM usage seems unreasonable. And because I haven't yet written enough, here are all the variations of the line I was working on that could've caused it. Pulled them out of my text editor's buffer. {{{ gnd grp = (ground (tiles w) ! fst $ head grp) gnd grp = (ground (tiles w) ! (fst $ head grp) gnd grp = (ground (tiles w) ! (fst $ head grp)) gnd grp = (ground ((tiles w) ! (fst $ head grp)) gnd grp = ground ((tiles w) ! (fst $ head grp)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 5 10:39:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Apr 2014 10:39:25 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.17ef6b7511e5db7f2fc4a1a8cb98dbf7@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): Today, I took a closer look, and actually it looks like profiling does have a hack to ensure that the constructor is loaded: {{{ -- Note [pipeline-split-init] -- If we have a stub file, it may contain constructor -- functions for initialisation of this module. We can't -- simply leave the stub as a separate object file, because it -- will never be linked in: nothing refers to it. We need to -- ensure that if we ever refer to the data in this module -- that needs initialisation, then we also pull in the -- initialisation routine. -- -- To that end, we make a DANGEROUS ASSUMPTION here: the data -- that needs to be initialised is all in the FIRST split -- object. See Note [codegen-split-init]. }}} (We probably annotate the link-step in the verbose output to this effect, as a reminder what the link step is doing). So the way to fix this problem here is to arrange for the first split object to contain the "data that needs to be initialized." In particular, all static closures have to be collected in the first split section. But this might actually be quite bad for split objects: with profiling, it is not a big deal if profiling data for a module is always loaded, since it doesn't contain any pointers to further data. But static closures contain pointers to their relevant code segments, and thus unconditionally loading the static closures could greatly increase the size of split-obj'd executables. I should probably implement this version and see how bad the bloat is, before we try to do something more complicated. Collecting this data through the compiler will be annoying, though, since it involves threading another list of SCCs through the various phases. If the static indirections table is placed in a single object file, which is a good idea, since otherwise the ordering of the various split object files which are linked together is not well-defined, then it may be very difficult to overcome this problem: the indirections table must point to the closures, and so if the indirections table is linked in, so are the rest of the objects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 5 12:01:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Apr 2014 12:01:09 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.2c42675186c47d2a73e9b6b65316ddfa@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): I have managed to fix this (not yet for kind!) using the tidying machinery from {{{ MkIface}}}. I first tried going through {{{IfaceDecl}}} as Simon suggested here and in #8776, but this gets really messy because as Gergo observed {{{tyThingToIfaceDecl}}} doesn't work for {{{RealDataCon}}}, and I also observed the same story for {{{ClassOpId}}} and this will require us keep {{{TyThing}}} in certain cases. I thing this will lead to code that is more complex and harder to understand in the long run. I also haven't looked into how this relates to #8776 but I thing we can also go without conversion to {{{IfaceDecl}}} in that case. I will have a patch ready in a couple of days(some other things came up) and after we further discuss the right aproach. Andrei -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 5 17:38:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Apr 2014 17:38:07 -0000 Subject: [GHC] #8958: Allow role inference on datatype contexts Message-ID: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> #8958: Allow role inference on datatype contexts ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, role inference on a datatype examines the use of a type parameter in all constructors of that datatype. This, of course, includes any constraint contexts on these datatypes. But, the (stupid) datatype context is not consulted, as there is no need to do so for type safety. However, by examining the datatype context, we can create a lightweight way of annotating roles, like this: {{{ class Nominal a instance Nominal a type role Nominal nominal -- this is redundant, but here for completeness class Representational a instance Representational a type role Representational representational -- this requires -XIncoherentInstances class Phantom a -- any use of this class is redundant, but here for completeness instance Phantom a type role Phantom phantom data (Nominal k, Representational v) => Map k v = ... }}} Because of the universal instances, these constraints never get in the way. This is admittedly an abuse of existing constructs, but it seems so useful that it's worth a little abuse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 5 20:04:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Apr 2014 20:04:49 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax Message-ID: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------------+------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | 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: -------------------------------------------+------------------------------- When we load a module into GHCi with -XUnicodeSyntax, GHCi should default to printing information with the relevant unicode symbols. {{{ *Communication> let a ? Int; a = 7 *Communication> :t a a :: Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 00:04:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 00:04:05 -0000 Subject: [GHC] #8958: Allow role inference on datatype contexts In-Reply-To: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> References: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> Message-ID: <062.054f004e456b9947e7b635f035055e14@haskell.org> #8958: Allow role inference on datatype contexts -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"d468cd376ffc02cf9f4755275a316be914c482be/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d468cd376ffc02cf9f4755275a316be914c482be" Fix #8958. We now do role inference on stupid datatype contexts, allowing a lightweight role annotation syntax. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 00:04:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 00:04:05 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.918d80549a484925f31e8db489a40250@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"f7723444fe70c37322a0ab21db21b3b7ac699f64/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f7723444fe70c37322a0ab21db21b3b7ac699f64" Add test case for #8950. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 00:06:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 00:06:07 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.da0779c9b59d30d88874c964360fd60c@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------------------+------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8950 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * testcase: => deriving/should_compile/T8950 Comment: Just added the test case I had written during my first pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 03:59:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 03:59:00 -0000 Subject: [GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 Message-ID: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 -----------------------------------+--------------------------------------- Reporter: MichalGajda | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: cabal install hPDB Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- GHC 7.8 rc2 exhausts all memory on `Bio.PDB.EventParser.PDBEventParser` module in -O3 mode, but not in -O2 mode. The tail of ''-v3'' input seems to indicate that it dies during SpecConstr phase. The module successfully compiled with below 2GB RAM since GHC 6.12, so I wonder why the memory use exploded with the most recent version. *** SpecConstr: ==================== SpecConstr ==================== Result size of SpecConstr STEPS TO REPRODUCE: 1. `cabal install hPDB` RESULT EXPECTED: Successful compilation and installation CURRENT RESULT: Exhausts available memory and crashes when compiling `Bio.PDB.EventParser.PDBEventParser`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 04:00:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 04:00:06 -0000 Subject: [GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 In-Reply-To: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> References: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> Message-ID: <065.ea59ffb89556fcfbb1c26d2f6190ae84@haskell.org> #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 ---------------------------------------+----------------------------------- Reporter: MichalGajda | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: cabal install hPDB | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by MichalGajda): Note that -O3 is indicated as default build parameter in the package .cabal file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 06:22:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 06:22:31 -0000 Subject: [GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 In-Reply-To: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> References: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> Message-ID: <065.4787ea564059990543336f43ff09f2f5@haskell.org> #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 ---------------------------------------+----------------------------------- Reporter: MichalGajda | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: cabal install hPDB | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 7068, 7898 ---------------------------------------+----------------------------------- Changes (by quantheory): * related: => 7068, 7898 Comment: I guess SpecConstr seems to cause this sort of problem at times, so adding related bugs. I'm confused about -O2 vs. -O3, though. I thought that -O2 was the maximum, so -O3 and -O2 should be exactly the same? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 06:24:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 06:24:38 -0000 Subject: [GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 In-Reply-To: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> References: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> Message-ID: <065.2023d6cd3b246083d2a6e0c89b43ca69@haskell.org> #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 ---------------------------------------+----------------------------------- Reporter: MichalGajda | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: cabal install hPDB | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #7068, #7898 ---------------------------------------+----------------------------------- Changes (by quantheory): * related: 7068, 7898 => #7068, #7898 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 13:19:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 13:19:18 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms Message-ID: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------------+------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.8.1-rc2 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: -------------------------------------------+------------------------------- To keep in the spirit of #2905, especially in light of the immaturity of the pattern synonyms extensions, GHC should require the `PatternSynonyms` language extension to be turned on when encountering a pattern synonym occurance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 14:15:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 14:15:21 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.3c9c82eba8a03758ace55abd8d9f7d02@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => merge Comment: Fixed via 60ec752c7e5378c8eeb556391ae34ab8c37426c4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 14:16:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 14:16:55 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.f1f160cf680c28b99c3dd933fc90794d@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by hvr): * owner: cactus => * status: merge => new Comment: nevermind, reverting status to new since this isn't yet in master -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 15:06:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 15:06:46 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.0c83ffa17c197adcc59139cc7c6d7fc0@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"8f831ec578d22419788542290e164c50524d90f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f831ec578d22419788542290e164c50524d90f6" Require PatternSynonyms language flag when encountering a use of pattern synonym (#8961) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 15:31:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 15:31:57 -0000 Subject: [GHC] #8958: Allow role inference on datatype contexts In-Reply-To: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> References: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> Message-ID: <062.6eb227da235f53915cf5d34d9f2f647f@haskell.org> #8958: Allow role inference on datatype contexts -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | goldfire Priority: normal | Status: merge Component: Compiler | Milestone: 7.8.1 Resolution: | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: roles/should_compile/T8958 | Architecture: Blocking: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by goldfire): * status: new => merge * testcase: => roles/should_compile/T8958 * milestone: => 7.8.1 Comment: This commit also fixed a latent bug in that the datatype context was not fully zonked in tcDataDefn. Please merge if possible into 7.8.1 -- this tiny patch allows lightweight role annotations, all done in user space, as suggested by Mark Lentczner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 16:35:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 16:35:03 -0000 Subject: [GHC] #8962: compile hang and memory blowup when using profiling and optimization Message-ID: <044.a9159e5a0f1565df240a29d6f9f6e9a9@haskell.org> #8962: compile hang and memory blowup when using profiling and optimization -------------------------+------------------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.8.1-rc2 Component: | Operating System: Linux Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: x86_64 (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- When I try to compile the following files: {{{ -- Vectorize.hs {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE TypeOperators #-} module Vectorize ( GVectorize(..) ) where import GHC.Generics import Data.Vector ( Vector ) import qualified Data.Vector as V gvlength :: GVectorize f => f a -> Int gvlength = V.length . gvectorize . (gempty `asFunctorOf`) where asFunctorOf :: f a -> f b -> f a asFunctorOf x _ = x class GVectorize f where gdevectorize :: Vector a -> f a gvectorize :: f a -> Vector a gempty :: f () instance (GVectorize f, GVectorize g) => GVectorize (f :*: g) where gdevectorize v0s | V.length v0s < n0 = error $ show n0 | otherwise = f0 :*: f1 where f0 = gdevectorize v0 f1 = gdevectorize v1 n0 = gvlength f0 (v0,v1) = V.splitAt n0 v0s gvectorize (f :*: g) = gvectorize f V.++ gvectorize g gempty = gempty :*: gempty instance GVectorize f => GVectorize (M1 i c f) where gdevectorize = M1 . gdevectorize gvectorize = gvectorize . unM1 gempty = undefined -- M1 gempty instance GVectorize Par1 where gdevectorize _ = undefined gvectorize = V.singleton . unPar1 gempty = undefined -- Par1 () }}} {{{ -- Woo.hs {-# OPTIONS_GHC -Wall #-} {-# Language DeriveGeneric #-} module Woo ( Woo(..) , devectorize ) where import GHC.Generics import Data.Vector ( Vector ) import Vectorize ( GVectorize(..) ) data Woo a = MkWoo { x00 :: a , x01 :: a , x02 :: a , x03 :: a , x04 :: a , x05 :: a , x06 :: a , x07 :: a , x08 :: a , x09 :: a , x10 :: a , x11 :: a , x12 :: a , x13 :: a , x14 :: a , x15 :: a , x16 :: a , x17 :: a , x18 :: a , x19 :: a , x20 :: a , x21 :: a } deriving (Generic1) devectorize :: Vector a -> Woo a devectorize = to1 . gdevectorize }}} with `ghc -O2 -prof -fprof-auto-calls Woo.hs`, GHC seems to hang on Woo.o and the memory usage steadily creeps up (I killed it at 5GB after about 5 minutes). I don't think this is #7068 / #7898 / #8960 because `-fno-spec-constr` doesn't fix it and the end of the -v3 output is: {{{ ... ... *** SpecConstr: Result size of SpecConstr = {terms: 89,855, types: 125,614, coercions: 138,597} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 428,416, types: 555,965, coercions: 855,101} Result size of Simplifier = {terms: 428,386, types: 555,815, coercions: 626,125} *** Tidy Core: Result size of Tidy Core = {terms: 428,386, types: 555,815, coercions: 626,125} writeBinIface: 190 Names writeBinIface: 495 dict entries *** CorePrep: Result size of CorePrep = {terms: 533,584, types: 600,927, coercions: 626,125} *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: }}} and then about another 100 lines of `*** CPSZ:` before it hangs. Removing either the optimization or profiling flags fixes the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 18:56:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 18:56:43 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.a63edc956bf1a770e5706606b22cc6e6@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): I'm quite reluctant to duplicate all that tidying machinery. Moreover, we need to pretty-print `IfaceDecl`s anyway, so this is just duplicating that. If there isn't enough information in `IfaceSyn`, maybe we should add a little more. For Gergo's point I was going to add an extra constructor to `IfaceType`, corresponding to `=>`, for example. Easy; and will improve the output from `--show-iface`. So by all means go ahead, and I will look, but I'm advertising that my instinct is still to take the approach I outlined. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 19:33:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 19:33:04 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.eaef5065c1294c120ee15d3de8b04d37@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): I do think you know what's best and I will look into exactly how much information needs to be added and write a patch. The reason I considered the other aproach was because I didn't really think modifying the iface implementation would be something you were willing to do just because of pretty printing purposes. Also there will not really be that much code duplication when doing separate tidying so I will try and have a patch with both aproaches next week and I'll also try to understand exactly how the iface interface should be extended and maybe start a discussion about that as I make progress. Andrei -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 6 23:17:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Apr 2014 23:17:46 -0000 Subject: [GHC] #8963: GeneralizedNewtypeDeriving unusable on associated types Message-ID: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> #8963: GeneralizedNewtypeDeriving unusable on associated types ------------------------------------+------------------------------------- Reporter: mojojojo | 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: | ------------------------------------+------------------------------------- This code: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} class C c where data F c r instance C Int where newtype F Int r = F (IO r) deriving (Functor) }}} fails to compile with the following message: {{{ Derived instance `Functor (F Int)' requires illegal partial application of data type family F In the newtype instance declaration for `F' }}} This might be related to https://ghc.haskell.org/trac/ghc/ticket/4185, but then it is marked as fixed in GHC 7.6.2, and I experience my error on 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 07:15:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 07:15:25 -0000 Subject: [GHC] #8937: Wrong jump target in stg_maskUninterruptiblezh In-Reply-To: <045.b6d0729cad4aed01f58fdf55a078a77f@haskell.org> References: <045.b6d0729cad4aed01f58fdf55a078a77f@haskell.org> Message-ID: <060.0ee004d494dac55674a0bc0adbd9f47d@haskell.org> #8937: Wrong jump target in stg_maskUninterruptiblezh -------------------------------------+------------------------------------ Reporter: hsjunn | Owner: simonmar Type: bug | Status: merge Priority: normal | Milestone: 7.8.2 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): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 09:16:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 09:16:35 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.3935fc71886ead06a5188d1bc573b4d2@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | 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 ghorn): * cc: gregmainland@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 10:16:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 10:16:03 -0000 Subject: [GHC] #8300: split-objs doesn't split on LLVM In-Reply-To: <047.984373a836be528107e61ac010d1d280@haskell.org> References: <047.984373a836be528107e61ac010d1d280@haskell.org> Message-ID: <062.a50b515079013fc4577c467a88385ec6@haskell.org> #8300: split-objs doesn't split on LLVM ----------------------------+---------------------------------------------- Reporter: | Owner: rwbarton | Status: new Type: feature | Milestone: request | Version: 7.7 Priority: normal | Keywords: Component: | Architecture: Unknown/Multiple Compiler (LLVM) | Difficulty: Moderate (less than a day) Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by ezyang): * difficulty: Unknown => Moderate (less than a day) Comment: The reason is the splitter needs 'split markers' (stg_split_marker) to know where to split, and at the moment, these markers are only emitted by the native backend. However, I imagine it would not be too difficult to teach the LLVM backend how to do it. You'd have another barrier, however; the splitter needs to be taught how to read LLVM code, in much the same way it needs to be taught how to read code for different architectures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 11:03:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 11:03:43 -0000 Subject: [GHC] #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm Message-ID: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- ...since the pretty-printer attempts to force the blocks list of the split_marker_entry proc. I'm not really sure what the right way to fix this is: just provide an empty block list, or hack the pretty-printer to treat split markers specially. But should be easy to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 11:13:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 11:13:17 -0000 Subject: [GHC] #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm In-Reply-To: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> References: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> Message-ID: <060.d62d5f19a2d73b39984bc2b3a8eeac97@haskell.org> #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: lowest | Milestone: ? Component: Compiler | Version: 7.9 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Easy (less than 1 crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by ezyang): * cc: simonmar (added) * status: new => closed * resolution: => invalid Comment: Relevant commit which switched from one to the other: {{{ commit d92bd17ffd8715f77fd49de0fed6e39c8d0ec28b Author: Simon Marlow Date: Mon Nov 12 11:47:51 2012 +0000 Remove OldCmm, convert backends to consume new Cmm This removes the OldCmm data type and the CmmCvt pass that converts new Cmm to OldCmm. The backends (NCGs, LLVM and C) have all been converted to consume new Cmm. The main difference between the two data types is that conditional branches in new Cmm have both true/false successors, whereas in OldCmm the false case was a fallthrough. To generate slightly better code we occasionally need to invert a conditional to ensure that the branch-not-taken becomes a fallthrough; this was previously done in CmmCvt, and it is now done in CmmContFlowOpt. We could go further and use the Hoopl Block representation for native code, which would mean that we could use Hoopl's postorderDfs and analyses for native code, but for now I've left it as is, using the old ListGraph representation for native code. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 11:13:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 11:13:31 -0000 Subject: [GHC] #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm In-Reply-To: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> References: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> Message-ID: <060.68ff8cc2c0724b9a63993a2bbda756ab@haskell.org> #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Easy (less than 1 crash | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by ezyang): * status: closed => new * resolution: invalid => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 11:25:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 11:25:54 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el Message-ID: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> #8965: bootstrapping failure on Linux/ppc64el -----------------------------+-------------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: GHC doesn't work at all Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+-------------------------------------------- A few distributions, including Ubuntu which I work on, have a new little- endian Linux ppc64 port (known variously as ppc64el, ppc64le, powerpc64le, etc.). As well as the obvious endianness difference, this varies from traditional ppc64 in that it uses a new version of the ELF ABI. https://bugs.openjdk.java.net/browse/JDK-8035647 has a useful set of links explaining the changes. I've been trying to bootstrap GHC on this architecture, but I've been running into failures, which I explained here along with my procedure: https://lists.ubuntu.com/archives/ubuntu-devel- discuss/2014-April/014922.html Things that I believe I have ruled out so far: * It's not libffi. In the above procedure I was missing unpacking libffi6:ppc64el in the sysroot and configuring using `--with-system- libffi` (our libffi is newer), but that makes no difference; furthermore, breakpoints set on all exposed `ffi_*` symbols and on `createAdjustor` never fire. * It's not signal handling. I replaced unlit with a shell script that sleeps 5 and then execs the real unlit, and ghc-stage2 segfaulted before it returned; strace shows that SIGSEGV is the first signal received. * It's not buggy native code generation. Although getting an NCG up on this platform might be tractable later, for now I added a `powerpc64le*) $2="powerpc64le" ;;` case before `powerpc64*` to `GHC_CONVERT_CPU` and added powerpc64le to the `ArchUnknown` list in `FPTOOLS_SET_HASKELL_PLATFORM_VARS`. Everything should be going via GCC. * I don't think I'm taking a fundamentally wrong bootstrapping approach; I'm using the exact same procedure and in fact I started from the exact same git tree that I just used to successfully bootstrap GHC on arm64. Here's a gdb trace showing the location of the segfault: {{{ *** Literate pre-processor: ../inplace/lib/unlit -h HelloWorld.lhs HelloWorld.lhs /tmp/ghc6597_0/ghc6597_1.lpp Breakpoint 1, 0x000000001507daac in runInteractiveProcess () (gdb) bt #0 0x000000001507daac in runInteractiveProcess () #1 0x000000001507d968 in c8z6_entry () #2 0x00003fffb7804a20 in ?? () Cannot access memory at address 0xf (gdb) finish Run till exit from #0 0x000000001507daac in runInteractiveProcess () 0x000000001507d968 in c8z6_entry () (gdb) stepi 0x000000001507d96c in c8z6_entry () (gdb) 0x000000001507d970 in c8z6_entry () (gdb) 0x000000001507d974 in c8z6_entry () (gdb) 0x000000001507d978 in c8z6_entry () (gdb) 0x000000001507d97c in c8z6_entry () (gdb) 0x000000001507d980 in c8z6_entry () (gdb) 0x000000001507d984 in c8z6_entry () (gdb) 0x000000001507d988 in c8z6_entry () (gdb) 0x000000001507d98c in c8z6_entry () (gdb) 0x000000001507d990 in c8z6_entry () (gdb) 0x000000001507d994 in c8z6_entry () (gdb) 0x000000001507d998 in c8z6_entry () (gdb) 0x000000001507d99c in c8z6_entry () (gdb) 0x000000001507d9a0 in c8z6_entry () (gdb) 0x000000001507d9a4 in c8z6_entry () (gdb) 0x000000001507d9a8 in c8z6_entry () (gdb) 0x000000001507d9ac in c8z6_entry () (gdb) 0x000000001507d9b0 in c8z6_entry () (gdb) 0x000000001507d9e8 in c8z6_entry () (gdb) Cannot access memory at address 0xf (gdb) disas /rm Dump of assembler code for function c8z6_entry: 0x000000001507d8ec <+0>: 6f 16 40 3c lis r2,5743 0x000000001507d8f0 <+4>: 20 9c 42 38 addi r2,r2,-25568 0x000000001507d8f4 <+8>: a6 02 08 7c mflr r0 0x000000001507d8f8 <+12>: 10 00 01 f8 std r0,16(r1) 0x000000001507d8fc <+16>: c1 ff 21 f8 stdu r1,-64(r1) 0x000000001507d900 <+20>: 00 00 00 60 nop 0x000000001507d904 <+24>: 60 92 22 39 addi r9,r2,-28064 0x000000001507d908 <+28>: 68 03 49 e9 ld r10,872(r9) 0x000000001507d90c <+32>: 10 00 4a 39 addi r10,r10,16 0x000000001507d910 <+36>: 68 03 49 f9 std r10,872(r9) 0x000000001507d914 <+40>: 58 03 69 e9 ld r11,856(r9) 0x000000001507d918 <+44>: 08 00 0b e8 ld r0,8(r11) 0x000000001507d91c <+48>: 70 03 29 e9 ld r9,880(r9) 0x000000001507d920 <+52>: 40 48 aa 7f cmpld cr7,r10,r9 0x000000001507d924 <+56>: 90 00 9d 41 bgt cr7,0x1507d9b4 0x000000001507d928 <+60>: 40 00 6b e8 ld r3,64(r11) 0x000000001507d92c <+64>: 38 00 8b e8 ld r4,56(r11) 0x000000001507d930 <+68>: 48 00 ab e8 ld r5,72(r11) 0x000000001507d934 <+72>: 50 00 cb e8 ld r6,80(r11) 0x000000001507d938 <+76>: 58 00 eb e8 ld r7,88(r11) 0x000000001507d93c <+80>: 10 00 0b e9 ld r8,16(r11) 0x000000001507d940 <+84>: 30 00 2b e9 ld r9,48(r11) 0x000000001507d944 <+88>: 28 00 4b e9 ld r10,40(r11) 0x000000001507d948 <+92>: 20 00 8b e9 ld r12,32(r11) 0x000000001507d94c <+96>: 20 00 81 f9 std r12,32(r1) 0x000000001507d950 <+100>: 00 00 8b e9 ld r12,0(r11) 0x000000001507d954 <+104>: 28 00 81 f9 std r12,40(r1) 0x000000001507d958 <+108>: 30 00 01 f8 std r0,48(r1) 0x000000001507d95c <+112>: 18 00 6b e9 ld r11,24(r11) 0x000000001507d960 <+116>: 38 00 61 f9 std r11,56(r1) 0x000000001507d964 <+120>: 19 01 00 48 bl 0x1507da7c 0x000000001507d968 <+124>: 00 00 00 60 nop 0x000000001507d96c <+128>: 00 00 00 60 nop 0x000000001507d970 <+132>: 60 92 22 39 addi r9,r2,-28064 0x000000001507d974 <+136>: 68 03 49 e9 ld r10,872(r9) 0x000000001507d978 <+140>: f6 ff e2 3c addis r7,r2,-10 0x000000001507d97c <+144>: 30 17 07 39 addi r8,r7,5936 0x000000001507d980 <+148>: f8 ff 0a f9 std r8,-8(r10) 0x000000001507d984 <+152>: 68 03 49 e9 ld r10,872(r9) 0x000000001507d988 <+156>: b4 07 63 7c extsw r3,r3 0x000000001507d98c <+160>: 00 00 6a f8 std r3,0(r10) 0x000000001507d990 <+164>: 68 03 49 e9 ld r10,872(r9) 0x000000001507d994 <+168>: f9 ff 4a 39 addi r10,r10,-7 0x000000001507d998 <+172>: 18 00 49 f9 std r10,24(r9) 0x000000001507d99c <+176>: 58 03 49 e9 ld r10,856(r9) 0x000000001507d9a0 <+180>: 60 00 0a 39 addi r8,r10,96 0x000000001507d9a4 <+184>: 58 03 09 f9 std r8,856(r9) 0x000000001507d9a8 <+188>: 60 00 2a e9 ld r9,96(r10) 0x000000001507d9ac <+192>: 00 00 69 e8 ld r3,0(r9) 0x000000001507d9b0 <+196>: 38 00 00 48 b 0x1507d9e8 0x000000001507d9b4 <+200>: 00 00 00 60 nop 0x000000001507d9b8 <+204>: 60 92 22 39 addi r9,r2,-28064 0x000000001507d9bc <+208>: 10 00 40 39 li r10,16 0x000000001507d9c0 <+212>: a0 03 49 f9 std r10,928(r9) 0x000000001507d9c4 <+216>: da ff 42 3d addis r10,r2,-38 0x000000001507d9c8 <+220>: 38 36 4a 39 addi r10,r10,13880 0x000000001507d9cc <+224>: f8 ff 4b f9 std r10,-8(r11) 0x000000001507d9d0 <+228>: 18 00 09 f8 std r0,24(r9) 0x000000001507d9d4 <+232>: 58 03 49 e9 ld r10,856(r9) 0x000000001507d9d8 <+236>: f8 ff 4a 39 addi r10,r10,-8 0x000000001507d9dc <+240>: 58 03 49 f9 std r10,856(r9) 0x000000001507d9e0 <+244>: 3b ff e2 3c addis r7,r2,-197 0x000000001507d9e4 <+248>: 60 c0 67 38 addi r3,r7,-16288 0x000000001507d9e8 <+252>: 40 00 21 38 addi r1,r1,64 => 0x000000001507d9ec <+256>: 10 00 01 e8 ld r0,16(r1) ---Type to continue, or q to quit--- 0x000000001507d9f0 <+260>: a6 03 08 7c mtlr r0 0x000000001507d9f4 <+264>: 20 00 80 4e blr 0x000000001507d9f8 <+268>: 00 00 00 00 .long 0x0 0x000000001507d9fc <+272>: 00 00 00 01 .long 0x1000000 0x000000001507da00 <+276>: 80 00 00 00 .long 0x80 End of assembler dump. (gdb) }}} Let me know what else I could try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 11:31:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 11:31:11 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.0b4499aab89c0b345517faa03bc1a36f@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): OK, here is the proposed approach. Since we won't have collected all the static closures in time to place them in the first `CmmGroup` (due to streaming), we merely have to change the convention so the *last* block contains the data that needs to be initialized. This might not be ideal for linker efficiency but it prevents a space leak. {{{ diff --git a/compiler/codeGen/StgCmm.hs b/compiler/codeGen/StgCmm.hs index e2a5a07..e9f5668 100644 --- a/compiler/codeGen/StgCmm.hs +++ b/compiler/codeGen/StgCmm.hs @@ -79,12 +79,6 @@ codeGen dflags this_mod data_tycons return a yield cmm - -- Note [codegen-split-init] the cmm_init block must come - -- FIRST. This is because when -split-objs is on we need to - -- combine this block with its initialisation routines; see - -- Note [pipeline-split-init]. - ; cg (mkModuleInit cost_centre_info this_mod hpc_info) - ; mapM_ (cg . cgTopBinding dflags) stg_binds -- Put datatype_stuff after code_stuff, because the @@ -99,6 +93,12 @@ codeGen dflags this_mod data_tycons mapM_ (cg . cgDataCon) (tyConDataCons tycon) ; mapM_ do_tycon data_tycons + + -- Note [codegen-split-init] the cmm_init block must come + -- FIRST. This is because when -split-objs is on we need to + -- combine this block with its initialisation routines; see + -- Note [pipeline-split-init]. + ; cg (mkModuleInit cost_centre_info this_mod hpc_info) } --------------------------------------------------------------- diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index 517ba6c..2f7b847 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1313,18 +1313,18 @@ runPhase (RealPhase SplitAs) _input_fn dflags -- initialisation routine. -- -- To that end, we make a DANGEROUS ASSUMPTION here: the data - -- that needs to be initialised is all in the FIRST split + -- that needs to be initialised is all in the LAST split -- object. See Note [codegen-split-init]. PipeState{maybe_stub_o} <- getPipeState case maybe_stub_o of Nothing -> return () Just stub_o -> liftIO $ do - tmp_split_1 <- newTempName dflags osuf - let split_1 = split_obj 1 - copyFile split_1 tmp_split_1 - removeFile split_1 - joinObjectFiles dflags [tmp_split_1, stub_o] split_1 + tmp_split_n <- newTempName dflags osuf + let split_n = split_obj n + copyFile split_n tmp_split_n + removeFile split_n + joinObjectFiles dflags [tmp_split_n, stub_o] split_n -- join them into a single .o file liftIO $ joinObjectFiles dflags (map split_obj [1..n]) output_fn diff --git a/compiler/main/HscMain.hs b/compiler/main/HscMain.hs index 26aca2a..97802b4 100644 --- a/compiler/main/HscMain.hs +++ b/compiler/main/HscMain.hs @@ -1670,13 +1670,36 @@ showModuleIndex (i,n) = "[" ++ padded ++ " of " ++ n_str ++ "] " i_str = show i padded = replicate (length n_str - length i_str) ' ' ++ i_str +-- Slightly inefficient, in that it needs to lookahead in order to +-- determine if it needs to cat the closures on immediatel +deferStaticClosures :: Monad m => + Either CLabel Module + -> Stream m [GenCmmDecl CmmStatics info stmt] b + -> [GenCmmDecl CmmStatics info stmt] + -> [GenCmmDecl CmmStatics info stmt] + -> Stream m [GenCmmDecl CmmStatics info stmt] b +deferStaticClosures lbl_or_mod str prev !closures = Stream.Stream $ do + r <- Stream.runStream str + case r of + Left x -> do + let addLabel starts = mkDataLits StaticClosureInds (mkStaticClosureIndsLabel lbl_or_mod starts) [] + return (Right (addLabel True : closures ++ [addLabel False] ++ prev, Stream.Stream (return (Left x)))) + Right (next, str') -> do + let isStaticClosure (CmmData StaticClosures _) = True + isStaticClosure (CmmData StaticClosureInds _) = True + isStaticClosure _ = False + newClosures = filter isStaticClosure next + next' = filter (not . isStaticClosure) next + closures' = newClosures `seq` (closures ++ newClosures) + if null prev + then Stream.runStream (deferStaticClosures lbl_or_mod str' next' closures') + else return (Right (prev, deferStaticClosures lbl_or_mod str' next' closures')) + prepareStaticClosures :: Monad m => Either CLabel Module -> Stream m [GenCmmDecl CmmStatics info stmt] b -> ForeignStubs -> (Stream m [GenCmmDecl CmmStatics info stmt] b, ForeignStubs) prepareStaticClosures lbl_or_mod cmms0 foreign_stubs0 = - let cmms = addLabel True >> cmms0 >>= (\r -> addLabel False >> return r) - addLabel starts = - Stream.yield [mkDataLits StaticClosureInds (mkStaticClosureIndsLabel lbl_or_mod starts) []] + let cmms = deferStaticClosures lbl_or_mod cmms0 [] [] foreign_stubs = foreign_stubs0 `appendStubC` static_closure_inds_init tag = case lbl_or_mod of Left lbl -> text "cmm_" <> ppr lbl }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 12:59:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 12:59:03 -0000 Subject: [GHC] #8966: Pattern synonyms and kind-polymorphism Message-ID: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> #8966: Pattern synonyms and kind-polymorphism -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- There's a strange interaction between pattern synonyms, GADTs, kind polymorphism and data kinds. The following module fails to compile with ghc-7.8.1-rc2, but I think it should: {{{ {-# LANGUAGE PolyKinds, KindSignatures, PatternSynonyms, DataKinds, GADTs #-} data NQ :: [k] -> * where D :: NQ '[a] pattern Q = D }}} I get the following error: {{{ KindPat.hs:6:13: Could not deduce (a ~ a0) from the context (t ~ '[a]) bound by the type signature for (Main.$WQ) :: t ~ '[a] => NQ t at KindPat.hs:6:9 ?a? is a rigid type variable bound by the type signature for (Main.$WQ) :: t ~ '[a] => NQ t at KindPat.hs:6:13 Expected type: NQ t Actual type: NQ '[a0] In the expression: D In an equation for ?$WQ?: ($WQ) = D }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:07:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:07:10 -0000 Subject: [GHC] #8958: Allow role inference on datatype contexts In-Reply-To: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> References: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> Message-ID: <062.8b5133727185a2006589b2efe1a8390f@haskell.org> #8958: Allow role inference on datatype contexts -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | goldfire Priority: normal | Status: closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: roles/should_compile/T8958 | Architecture: Blocking: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:08:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:08:38 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.c97fe7cf0045eb69ba61149e551b0a92@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+----------------------------- Reporter: facundoq | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+----------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:08:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:08:57 -0000 Subject: [GHC] #8931: The type defaulting in GHCi with Typeable In-Reply-To: <044.24193734a44f208446e00dfc5621ccaf@haskell.org> References: <044.24193734a44f208446e00dfc5621ccaf@haskell.org> Message-ID: <059.2fe5c79367715fc2d30d9fdaf9bf197b@haskell.org> #8931: The type defaulting in GHCi with Typeable -------------------------------------+------------------------------------- Reporter: skata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: type defaulting, Resolution: fixed | Typeable Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: ghci/scripts/T8931 | Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:09:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:09:12 -0000 Subject: [GHC] #8937: Wrong jump target in stg_maskUninterruptiblezh In-Reply-To: <045.b6d0729cad4aed01f58fdf55a078a77f@haskell.org> References: <045.b6d0729cad4aed01f58fdf55a078a77f@haskell.org> Message-ID: <060.6871e4aad6d3309ba33e960b857cd505@haskell.org> #8937: Wrong jump target in stg_maskUninterruptiblezh -------------------------------------+------------------------------------ Reporter: hsjunn | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 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: merge => closed * resolution: => fixed * milestone: 7.8.2 => 7.8.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:09:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:09:23 -0000 Subject: [GHC] #8952: Bang patterns don't work as the specification says In-Reply-To: <044.1fc82652e793a6a52c046d6f18c243a4@haskell.org> References: <044.1fc82652e793a6a52c046d6f18c243a4@haskell.org> Message-ID: <059.0e6c9300eaa9a6c7b267a8d8c25f5cf8@haskell.org> #8952: Bang patterns don't work as the specification says ------------------------------------------------+-------------------------- Reporter: dolio | 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: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: deSugar/should_run/T8952 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:10:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:10:07 -0000 Subject: [GHC] #8954: Reifying the nullary unboxed tuple is broken In-Reply-To: <047.db7c3dce80c2c09f762efbd3c1842bf1@haskell.org> References: <047.db7c3dce80c2c09f762efbd3c1842bf1@haskell.org> Message-ID: <062.0ab2b97fc8fbd5f64bab626624072750@haskell.org> #8954: Reifying the nullary unboxed tuple is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: low | Milestone: 7.8.2 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8954 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:10:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:10:17 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.278bd84281bb3ff1b33acc7ddedc79a5@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:25:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:25:28 -0000 Subject: [GHC] #8932: Panic with TemplateHaskell and duplicate indentifiers In-Reply-To: <048.cd6ad88ea09e222679040103b1a3c25b@haskell.org> References: <048.cd6ad88ea09e222679040103b1a3c25b@haskell.org> Message-ID: <063.df83c59d2f8665a3adb92b0cc61a67e1@haskell.org> #8932: Panic with TemplateHaskell and duplicate indentifiers ---------------------------------------+----------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1-rc2 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 Simon Peyton Jones ): In [changeset:"d8d798b1b33ab0593ed03f193360b8725ba2c2ba/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d8d798b1b33ab0593ed03f193360b8725ba2c2ba" Small issue with signatures in a TH splice (fixes Trac #8932) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:42:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:42:09 -0000 Subject: [GHC] #8942: Duplicate symbol error when loading an archive twice In-Reply-To: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> References: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> Message-ID: <061.f8b2217f7d74532b771f847b8e027d12@haskell.org> #8942: Duplicate symbol error when loading an archive twice -----------------------------------+------------------------------------ Reporter: gelisam | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"ee481ffbd70e3ac3586bb7ab92f276e509a3579e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ee481ffbd70e3ac3586bb7ab92f276e509a3579e" Ignore repeated loads of the same archive (#8942) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:54:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:54:36 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.0d7805c498c13ae3ad50abc2e4d4260c@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): Is this documented in the user manual? If not, could it be, please? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:55:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:55:19 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.8b6aede62438fa93d2b4ba87e126ea7f@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:55:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:55:31 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.bf00522c5d405f02ffdcc48206bc6321@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => cactus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:56:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:56:52 -0000 Subject: [GHC] #8958: Allow role inference on datatype contexts In-Reply-To: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> References: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> Message-ID: <062.ad387eec09cca59f72657bf6d05225d3@haskell.org> #8958: Allow role inference on datatype contexts -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: roles/should_compile/T8958 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by simonpj): * owner: goldfire => * status: closed => new * resolution: fixed => Comment: I can see the motivation here, though it is a grievous hack. But it needs documenting in the user manual! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 14:57:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 14:57:03 -0000 Subject: [GHC] #8958: Allow role inference on datatype contexts In-Reply-To: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> References: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> Message-ID: <062.36c4bc9f2a8796c1302ae1d88e7dd004@haskell.org> #8958: Allow role inference on datatype contexts -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | goldfire Priority: normal | Status: new Component: Compiler | Milestone: 7.8.1 Resolution: | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: roles/should_compile/T8958 | Architecture: Blocking: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by simonpj): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:00:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:00:42 -0000 Subject: [GHC] #8932: Panic with TemplateHaskell and duplicate indentifiers In-Reply-To: <048.cd6ad88ea09e222679040103b1a3c25b@haskell.org> References: <048.cd6ad88ea09e222679040103b1a3c25b@haskell.org> Message-ID: <063.8ad83b476b78785f3dbeea7a20ba8ef7@haskell.org> #8932: Panic with TemplateHaskell and duplicate indentifiers ---------------------------------------+----------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: th/T8932 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => merge * testcase: => th/T8932 Comment: Thanks for discovering this. Now fixed. Merge to the 7.8 branch, but don't hold up the release for it. 7.8.2 would do. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:28:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:28:12 -0000 Subject: [GHC] #8967: Add syntax for creating finite maps and sets Message-ID: <044.fe1b7f69fd77fe9c6b0017a53bbe1a36@haskell.org> #8967: Add syntax for creating finite maps and sets ------------------------------------+------------------------------------- Reporter: tibbe | 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: | ------------------------------------+------------------------------------- Many languages have syntax for creating maps. Commonly used syntax is either {{{ {key1: value1, key2: value2, ...} }}} or {{{ {key1 => value1, key2 => value2, ...} }}} Since few Haskellers (with the notable exception of SPJ) use the curly bracket Haskell syntax for layout, I thought we could co-opt it and instead use it for map (and set literals.) The feature would of course be protected by a language pragma as to not break old code. Strawman proposal: `{key1: value1, key2: value2, ...}` desugars to `fromList [(key1, value1), (key2, value2), ...]`, using a new type class: {{{#!haskell class IsMap m where type Key m type Value m fromList :: [(Key m, Value m)] -> m }}} `{:}` is the literal for empty maps. Analogously, `{value1, value2, ...}` desugars to `fromList [value1, value2, ...]`, using a new type class: {{{#!haskell class IsSet m where type Item m fromList :: [Item m] -> m }}} `{}` is the literal for empty sets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:29:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:29:20 -0000 Subject: [GHC] #8967: Add syntax for creating finite maps and sets In-Reply-To: <044.fe1b7f69fd77fe9c6b0017a53bbe1a36@haskell.org> References: <044.fe1b7f69fd77fe9c6b0017a53bbe1a36@haskell.org> Message-ID: <059.5de97c149476e91fcb935b09b97e54d1@haskell.org> #8967: Add syntax for creating finite maps and sets -------------------------------------+------------------------------------ Reporter: tibbe | 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: -------------------------------------+------------------------------------ Description changed by tibbe: Old description: > Many languages have syntax for creating maps. Commonly used syntax is > either > > {{{ > {key1: value1, key2: value2, ...} > }}} > > or > > {{{ > {key1 => value1, key2 => value2, ...} > }}} > > Since few Haskellers (with the notable exception of SPJ) use the curly > bracket Haskell syntax for layout, I thought we could co-opt it and > instead use it for map (and set literals.) The feature would of course be > protected by a language pragma as to not break old code. > > Strawman proposal: > > `{key1: value1, key2: value2, ...}` desugars to `fromList [(key1, > value1), (key2, value2), ...]`, using a new type class: > > {{{#!haskell > class IsMap m where > type Key m > type Value m > > fromList :: [(Key m, Value m)] -> m > }}} > > `{:}` is the literal for empty maps. > > Analogously, `{value1, value2, ...}` desugars to `fromList [value1, > value2, ...]`, using a new type class: > > {{{#!haskell > class IsSet m where > type Item m > > fromList :: [Item m] -> m > }}} > > `{}` is the literal for empty sets. New description: Many languages have syntax for creating maps. Commonly used syntax is either {{{ {key1: value1, key2: value2, ...} }}} or {{{ {key1 => value1, key2 => value2, ...} }}} Since few Haskellers (with the notable exception of SPJ) use the curly bracket Haskell syntax for layout, I thought we could co-opt it and instead use it for map (and set literals.) The feature would of course be protected by a language pragma as to not break old code. Strawman proposal: `{key1: value1, key2: value2, ...}` desugars to `fromList [(key1, value1), (key2, value2), ...]`, using a new type class: {{{#!haskell class IsMap m where type Key m type Value m fromList :: [(Key m, Value m)] -> m }}} `{:}` is the literal for empty maps. Analogously, `{value1, value2, ...}` desugars to `fromList [value1, value2, ...]`, using a new type class: {{{#!haskell class IsSet m where type Item m fromList :: [Item m] -> m }}} `{}` is the literal for empty sets. Both the containers and unordered-containers packages would presumably provide instances. It's possible that mutable data structures, such as those provided by the hashtables package, could provide instances as well. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:31:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:31:23 -0000 Subject: [GHC] #8967: Add syntax for creating finite maps and sets In-Reply-To: <044.fe1b7f69fd77fe9c6b0017a53bbe1a36@haskell.org> References: <044.fe1b7f69fd77fe9c6b0017a53bbe1a36@haskell.org> Message-ID: <059.d11b4f06bec03e16dc039255005258a7@haskell.org> #8967: Add syntax for creating finite maps and sets -------------------------------------+------------------------------------ Reporter: tibbe | 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: -------------------------------------+------------------------------------ Description changed by tibbe: Old description: > Many languages have syntax for creating maps. Commonly used syntax is > either > > {{{ > {key1: value1, key2: value2, ...} > }}} > > or > > {{{ > {key1 => value1, key2 => value2, ...} > }}} > > Since few Haskellers (with the notable exception of SPJ) use the curly > bracket Haskell syntax for layout, I thought we could co-opt it and > instead use it for map (and set literals.) The feature would of course be > protected by a language pragma as to not break old code. > > Strawman proposal: > > `{key1: value1, key2: value2, ...}` desugars to `fromList [(key1, > value1), (key2, value2), ...]`, using a new type class: > > {{{#!haskell > class IsMap m where > type Key m > type Value m > > fromList :: [(Key m, Value m)] -> m > }}} > > `{:}` is the literal for empty maps. > > Analogously, `{value1, value2, ...}` desugars to `fromList [value1, > value2, ...]`, using a new type class: > > {{{#!haskell > class IsSet m where > type Item m > > fromList :: [Item m] -> m > }}} > > `{}` is the literal for empty sets. > > Both the containers and unordered-containers packages would presumably > provide instances. It's possible that mutable data structures, such as > those provided by the hashtables package, could provide instances as > well. New description: Many languages have syntax for creating maps. Commonly used syntax is either {{{ {key1: value1, key2: value2, ...} }}} or {{{ {key1 => value1, key2 => value2, ...} }}} Since few Haskellers (with the notable exception of SPJ) use the curly bracket Haskell syntax for layout, I thought we could co-opt it and instead use it for map (and set literals.) The feature would of course be protected by a language pragma as to not break old code. Strawman proposal: `{key1: value1, key2: value2, ...}` desugars to `fromList [(key1, value1), (key2, value2), ...]`, using a new type class: {{{#!haskell class IsMap m where type Key m type Value m fromList :: [(Key m, Value m)] -> m }}} `{:}` is the literal for empty maps. Analogously, `{value1, value2, ...}` desugars to `fromList [value1, value2, ...]`, using a new type class: {{{#!haskell class IsSet m where type Item m fromList :: [Item m] -> m }}} `{}` is the literal for empty sets. Both the containers and unordered-containers packages would presumably provide instances. It's possible that mutable data structures, such as those provided by the hashtables package, could provide instances as well. **Open question**: will this clash badly with the record syntax? It seems to work in other languages which use `{` and `}` to define other entities. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:32:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:32:20 -0000 Subject: [GHC] #8942: Duplicate symbol error when loading an archive twice In-Reply-To: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> References: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> Message-ID: <061.57818b16c29fe2875a9da8debc47e777@haskell.org> #8942: Duplicate symbol error when loading an archive twice -----------------------------------+------------------------------------ Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Changes (by simonmar): * owner: simonmar => * status: patch => new Comment: Still need a test for this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:32:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:32:29 -0000 Subject: [GHC] #8942: Duplicate symbol error when loading an archive twice In-Reply-To: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> References: <046.0073cee3c08e66b73b01434c442d5dd0@haskell.org> Message-ID: <061.dfc304b30b20d44f0cfb7b41e4de34a1@haskell.org> #8942: Duplicate symbol error when loading an archive twice -----------------------------------+------------------------------------ Reporter: gelisam | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:33:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:33:21 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.3bf4bc60ed92a8d02116d36ff6503444@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------------------+------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8950 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"54e655536ecf7eba755b334058d5c22dab251bea/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="54e655536ecf7eba755b334058d5c22dab251bea" Derive Typable for promoted data constructors (Trac #8950) I got sucked into a significant refactoring of the way that Typeable instances are derived. This makes it simpler and more uniform. I also improved the documentation in the user manual. Typeable really is different to other classes, and now gets its own subsection. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:34:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:34:36 -0000 Subject: [GHC] #8966: Pattern synonyms and kind-polymorphism In-Reply-To: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> References: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> Message-ID: <062.5997130c4677380f23e0ed9207b9e7ef@haskell.org> #8966: Pattern synonyms and kind-polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * owner: => simonpj Comment: Thanks. A zonking step is missing. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:36:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:36:14 -0000 Subject: [GHC] #8950: Typeable instances for promoted lists and tuples In-Reply-To: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> References: <047.5987f5d5a50e6c231544d315d9330e5c@haskell.org> Message-ID: <062.ece9ea979a0e5ffefb3fb5c5c8971850@haskell.org> #8950: Typeable instances for promoted lists and tuples -------------------------------------------------+------------------------- Reporter: kosmikus | Owner: Type: bug | Status: Priority: normal | closed Component: libraries/base | Milestone: Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: deriving/should_compile/T8950 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: This actually slightly changes which Typeable instances are generated, so I suppose we'd better not merge it to the 7.8 branch unless it gets into 7.8.1 (and it's probably too late for that). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:36:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:36:36 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs Message-ID: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> #8968: Pattern synonyms and GADTs -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I think this one is different from #8966, but feel free to close one as duplicate if it turns out to be the same problem. The following program (using GADTs and pattern synonyms, but not kind polymorphism or data kinds) fails to check with ghc-7.8.1-rc2, but I think it should: {{{ {-# LANGUAGE GADTs, KindSignatures, PatternSynonyms #-} data X :: (* -> *) -> * -> * where Y :: f Int -> X f Int pattern C x = Y (Just x) }}} The error I get is the following: {{{ PatKind.hs:6:18: Couldn't match type ?t? with ?Maybe? ?t? is untouchable inside the constraints (t1 ~ Int) bound by a pattern with constructor Y :: forall (f :: * -> *). f Int -> X f Int, in a pattern synonym declaration at PatKind.hs:6:15-24 ?t? is a rigid type variable bound by the inferred type of C :: X t t1 x :: Int at PatKind.hs:1:1 Expected type: t Int Actual type: Maybe Int In the pattern: Just x In the pattern: Y (Just x) PatKind.hs:6:18: Could not deduce (t ~ Maybe) from the context (t1 ~ Int) bound by the type signature for (Main.$WC) :: t1 ~ Int => Int -> X t t1 at PatKind.hs:6:9 ?t? is a rigid type variable bound by the type signature for (Main.$WC) :: t1 ~ Int => Int -> X t t1 at PatKind.hs:1:1 Expected type: t Int Actual type: Maybe Int Relevant bindings include ($WC) :: Int -> X t t1 (bound at PatKind.hs:6:9) In the first argument of ?Y?, namely ?(Just x)? In the expression: Y (Just x) }}} Note that I'd be perfectly happy to provide a type signature for the pattern synonym, but I don't know of any syntax I could use. The Wiki page at https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms mentions I might be able to write {{{ pattern C :: Int -> X Maybe Int }}} but this triggers a parse error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 15:43:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 15:43:59 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.53799398881865f0908b350575b60a76@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Changes (by maeder): * status: new => patch Comment: The patch worked under 64bit windows https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2, too -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 16:08:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 16:08:42 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.b7fceacbde29c6e52a4abb6dd8f49fe9@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: I went ahead and added this to the manual and cherry-picked it into 7.8, thanks for the note Simon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 16:09:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 16:09:58 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.15277b73c6bbae025bd70566f5c96281@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by isaacdupree): I'm sceptical of this change. It means a library module can't transparently replace a data type with a pattern synonym in a new version. Modules that depend on the library would break unless they add a flag. Unlike with GADTs, this ability is one of the reasons for pattern synonyms existing. (The consistency and immaturity arguments are tempting, though.) Is there a technical reason along the lines of #2905's `RelaxedPolyRec` that makes pattern-matching pattern synonyms work poorly without a language extension? -Isaac -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 16:28:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 16:28:22 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.d8fc2545d7b2d287e0d7dd257bef261b@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by tibbe): I think it's very attractive to allow the change to be transparent to the user, as Isaac said. Imagine we want to change `String` to be an opaque type with a different representation. We could use a pattern synonym (and expression synonym?) to allow users who use `(:)` to be none the wiser. I admit that I haven't thought about all the implications though. Would it really be transparent to the user if a real constructor or a synonym is used? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 19:44:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 19:44:53 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.97fe427d67a8469e56c386fc0c56e15b@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): I was sceptical too. GHC's general convention is to require an extension at the ''definition'' site of something, but not its ''use'' site. For example, you can use a kind-polymorphic type constructor without `PolyKinds`; and you can use overlapping instances without `OverlappingInstances`. Really the only justification for not following this convention is if it's going to be hard for the user to understand what's going on. For example, a uni-directional pattern synonym can be used in a pattern but not an expression, and that would be puzzling if you had no idea that `K` is a pattern synonym. Also pattern matching on a pattern synonym might be much more expensive than pattern matching on a data constructor. And that kind of thing was the justification for #2905. FWIW, my own instinct is ''not'' to require `PatternSynonyms` at the use site; but I didn't feel strongly about it to reverse the choice. And it's easier to lift the restriction later than to add it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 21:07:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 21:07:37 -0000 Subject: [GHC] #8969: GHCi crash on invalid input Message-ID: <047.4e103fe86f8b03e0bcb63fd09c437d88@haskell.org> #8969: GHCi crash on invalid input ------------------------------------+------------------------------------- Reporter: aslpavel | 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: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I know its incorrect haskell code but after entering following sequence of commands, ghci seems to be crashing. {{{ 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. ? > data R = R { x1 :: Int, x2 :: Int, x3 :: Int } deriving Show ? > data R a = State { x1 :: Int, x2 :: Int, x3 :: Int } a ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tc_hs_type: record Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I hope it would be helpful. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 21:11:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 21:11:08 -0000 Subject: [GHC] #8969: GHCi crash on invalid input In-Reply-To: <047.4e103fe86f8b03e0bcb63fd09c437d88@haskell.org> References: <047.4e103fe86f8b03e0bcb63fd09c437d88@haskell.org> Message-ID: <062.6e5c6d5214da8be6b8d57529d378dca5@haskell.org> #8969: GHCi crash on invalid input -------------------------------------+------------------------------------ Reporter: aslpavel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This is already fixed in the development version (which will become GHC 7.8): #7943. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 21:16:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 21:16:15 -0000 Subject: [GHC] #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies Message-ID: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies ------------------------------------+------------------------------------- Reporter: tensor5 | 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: | ------------------------------------+------------------------------------- The code is: {{{ data K = Foo | Bar data D1 :: K -> * where F1 :: D1 Foo B1 :: D1 Bar class C (a :: K -> *) where data D2 a :: K -> * foo :: a k -> D2 a k -> Bool instance C D1 where data D2 D1 k where F2 :: D2 D1 Foo B2 :: D2 D1 Bar foo F1 F2 = True foo B1 B2 = True }}} With -Wall it gives the warning: {{{ Test.hs:23:5: Warning: Pattern match(es) are non-exhaustive In an equation for `foo': Patterns not matched: F1 B2 B1 F2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 7 21:30:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Apr 2014 21:30:12 -0000 Subject: [GHC] #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies In-Reply-To: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> References: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> Message-ID: <061.d30ccfdf6b8e736f4431666020160def@haskell.org> #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies -------------------------------------------------+------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by tensor5): * failure: None/Unknown => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 03:14:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 03:14:37 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... Message-ID: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... ------------------------------+-------------------------------------------- Reporter: | Owner: GordonBGood | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1-rc2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- The output assembly code is not as optimized for the Windows 32-bit version 7.8.1 RC2 compiler as the Windows 7.6.3 compiler (32-bit) when the option switches are exactly the same although it may not be limited to only the Windows platform; this has a negative impact on execution time for tight loops of about a factor of two times slower. The following code will reproduce the problem: {{{#!haskell -- GHC_NCG_OptimizationBug.hs -- it seems the Haskell GHC 7.8.1 NCG Native Code Generator (NCG) doesn't -- optimize as well for (at least) the x86 target as version 7.6.3 {-# OPTIONS_GHC -O3 -rtsopts -v -dcore-lint -ddump-asm -ddump-to-file -dumpdir . #-} -- or O2 import Data.Bits import Control.Monad.ST (runST,ST(..)) import Data.Array.Base -- Uses a very simple Sieve of Eratosthenes to 2 ^ 18 to prove it. accNumPrimes :: Int -> Int accNumPrimes acc = acc `seq` runST $ do let bfSz = (256 * 1024 - 3) `div` 2 bfLmtWrds = (bfSz + 1) `div` 32 bufw <- newArray (0, bfLmtWrds) (-1) :: ST s (STUArray s Int Int) -- to clear the last "uneven" bit(s) unsafeWrite bufw bfLmtWrds (complement ((-2) `shiftL` (bfSz .&. 31))) bufb <- (castSTUArray :: STUArray s Int Int -> ST s (STUArray s Int Bool)) bufw let cullp i = let p = i + i + 3 in let s = (p * p - 3) `div` 2 in if s > bfSz then let count i sm = do sm `seq` if i > bfLmtWrds then return (acc + sm) else do wd <- unsafeRead bufw i count (i + 1) (sm + (popCount wd)) in count 0 1 -- use '1' for the '2' prime not in the array else do v <- unsafeRead bufb i if v then let cull j = do -- very tight inner loop if j > bfSz then cullp (i + 1) else do unsafeWrite bufb j False cull (j + p) in cull s else cullp (i + 1) cullp 0 main = -- run the program a number of times to get a reasonable time... let numloops = 2000 in let loop n acc = acc `seq` if n <= 0 then acc else loop (n - 1) (accNumPrimes acc) in print $ loop numloops 0 }}} The above code takes almost twice as long to run when compiled under 7.8.1 RC2 for Windows (32-bit) as it does for the version 7.6.3 compiler (both 32-bit compilers). The -ddump-simpl Core dump is almost identical between the two, which is also evidenced by that using the -fllvm LLVM compiler back end switch for each results in code that runs at about the same speed for each compiler run (which would use the same Core output as used for NCG, right?). Under Windows, the compilation and run for 7.8.1 RC2 goes like this: {{{ *Main> :! E:\ghc-7.8.0.20140228_32\bin\ghc --make -pgmlo "E:\llvm32\build\Release\bin\opt" -pgmlc "E:\llvm32\build\Release\bin\llc" "GHC_NCG_OptimizationBug.hs" compile: input file WindowsVsLinuxNCG.hs Created temporary directory: C:\Users\Gordon\AppData\Local\Temp\ghc15460_0 *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: [1 of 1] Compiling Main ( GHC_NCG_OptimizationBug.hs, GHC_NCG_OptimizationBug.o ) *** Desugar: Result size of Desugar (after optimization) = {terms: 260, types: 212, coercions: 0} *** Core Linted result of Desugar (after optimization): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 213, types: 136, coercions: 52} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 215, types: 148, coercions: 67} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 209, types: 135, coercions: 51} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 209, types: 135, coercions: 42} *** Core Linted result of Simplifier: *** Specialise: Result size of Specialise = {terms: 209, types: 135, coercions: 42} *** Core Linted result of Specialise: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 286, types: 185, coercions: 42} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): *** Float inwards: Result size of Float inwards = {terms: 286, types: 185, coercions: 42} *** Core Linted result of Float inwards: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 502, types: 393, coercions: 103} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 428, types: 326, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 420, types: 321, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 420, types: 321, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 418, types: 318, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 418, types: 318, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 475, types: 383, coercions: 32} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 444, types: 336, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 444, types: 336, coercions: 9} *** Core Linted result of Simplifier: *** Demand analysis: Result size of Demand analysis = {terms: 444, types: 336, coercions: 9} *** Core Linted result of Demand analysis: *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 579, types: 457, coercions: 9} *** Core Linted result of Worker Wrapper binds: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 510, types: 415, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 420, types: 322, coercions: 9} *** Core Linted result of Simplifier: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}) = {terms: 426, types: 326, coercions: 9} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): *** Common sub-expression: Result size of Common sub-expression = {terms: 424, types: 326, coercions: 9} *** Core Linted result of Common sub-expression: *** Float inwards: Result size of Float inwards = {terms: 424, types: 326, coercions: 9} *** Core Linted result of Float inwards: *** Liberate case: Result size of Liberate case = {terms: 1,824, types: 1,259, coercions: 9} *** Core Linted result of Liberate case: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 608, types: 422, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 604, types: 413, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 604, types: 413, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 604, types: 413, coercions: 9} *** Core Linted result of Simplifier: *** SpecConstr: Result size of SpecConstr = {terms: 708, types: 505, coercions: 9} *** Core Linted result of SpecConstr: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 702, types: 499, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 608, types: 405, coercions: 9} *** Core Linted result of Simplifier: *** Tidy Core: Result size of Tidy Core = {terms: 608, types: 405, coercions: 9} *** Core Linted result of Tidy Core: *** CorePrep: Result size of CorePrep = {terms: 825, types: 489, coercions: 9} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** Assembler: "E:\ghc-7.8.0.20140228_32\lib/../mingw/bin/gcc.exe" "-U__i686" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-I." "-x" "assembler-with-cpp" "-c" "C:\Users\Gordon\AppData\Local\Temp\ghc15460_0\ghc15460_2.s" "-o" "GHC_NCG_OptimizationBug.o" Linking GHC_NCG_OptimizationBug.exe ... *Main> :! GHC_NCG_OptimizationBug +RTS -s 46000000 32,965,096 bytes allocated in the heap 7,032 bytes copied during GC 41,756 bytes maximum residency (2 sample(s)) 19,684 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 61 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 2 colls, 0 par 0.00s 0.00s 0.0001s 0.0001s INIT time 0.00s ( 0.00s elapsed) MUT time 1.73s ( 1.73s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.73s ( 1.73s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 19,006,902 bytes per MUT second Productivity 100.0% of total user, 100.2% of total elapsed }}} whereas under version 7.6.3 goes like this: {{{ *Main> :! E:\ghc-7.6.3_32\bin\ghc --make -pgmlo "E:\llvm32\build\Release\bin\opt" -pgmlc "E:\llvm32\build\Release\bin\llc" "GHC_NCG_OptimizationBug.hs" compile: input file GHC_NCG_OptimizationBug.hs Created temporary directory: C:\Users\Gordon\AppData\Local\Temp\ghc28200_0 *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: [1 of 1] Compiling Main ( GHC_NCG_OptimizationBug.hs, GHC_NCG_OptimizationBug.o ) *** Desugar: Result size of Desugar (after optimization) = {terms: 247, types: 212, coercions: 0} *** Core Linted result of Desugar (after optimization): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 198, types: 132, coercions: 35} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 200, types: 144, coercions: 43} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 194, types: 131, coercions: 57} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 194, types: 131, coercions: 39} *** Core Linted result of Simplifier: *** Specialise: Result size of Specialise = {terms: 194, types: 131, coercions: 39} *** Core Linted result of Specialise: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 277, types: 191, coercions: 39} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): *** Float inwards: Result size of Float inwards = {terms: 277, types: 191, coercions: 39} *** Core Linted result of Float inwards: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 514, types: 403, coercions: 103} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 420, types: 317, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 412, types: 312, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 412, types: 312, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 410, types: 309, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 410, types: 309, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 455, types: 364, coercions: 32} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 422, types: 317, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 422, types: 317, coercions: 9} *** Core Linted result of Simplifier: *** Demand analysis: Result size of Demand analysis = {terms: 422, types: 317, coercions: 9} *** Core Linted result of Demand analysis: *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 536, types: 427, coercions: 9} *** Core Linted result of Worker Wrapper binds: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 480, types: 391, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 400, types: 306, coercions: 9} *** Core Linted result of Simplifier: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}) = {terms: 408, types: 311, coercions: 9} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): *** Common sub-expression: Result size of Common sub-expression = {terms: 406, types: 311, coercions: 9} *** Core Linted result of Common sub-expression: *** Float inwards: Result size of Float inwards = {terms: 406, types: 311, coercions: 9} *** Core Linted result of Float inwards: *** Liberate case: Result size of Liberate case = {terms: 1,186, types: 824, coercions: 9} *** Core Linted result of Liberate case: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 585, types: 411, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 569, types: 392, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 569, types: 392, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 569, types: 392, coercions: 9} *** Core Linted result of Simplifier: *** SpecConstr: Result size of SpecConstr = {terms: 746, types: 566, coercions: 9} *** Core Linted result of SpecConstr: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 739, types: 560, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 762, types: 546, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 642, types: 402, coercions: 9} *** Core Linted result of Simplifier: *** Tidy Core: Result size of Tidy Core = {terms: 642, types: 402, coercions: 9} *** Core Linted result of Tidy Core: writeBinIface: 10 Names writeBinIface: 34 dict entries *** CorePrep: Result size of CorePrep = {terms: 779, types: 483, coercions: 9} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeOutput: *** CodeGen: *** Assembler: "E:\ghc-7.6.3_32\lib/../mingw/bin/gcc.exe" "-fno-stack-protector" "-Wl ,--hash-size=31" "-Wl,--reduce-memory-overheads" "-I." "-c" "C:\Users\Gordon\AppData\Local\Temp\ghc28200_0\ghc28200_0.s" "-o" "GHC_NCG_OptimizationBug.o" Linking GHC_NCG_OptimizationBug.exe ... *Main> :! GHC_NCG_OptimizationBug +RTS -s 46000000 32,989,396 bytes allocated in the heap 4,976 bytes copied during GC 41,860 bytes maximum residency (2 sample(s)) 19,580 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 61 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 2 colls, 0 par 0.00s 0.00s 0.0001s 0.0001s INIT time 0.00s ( 0.00s elapsed) MUT time 0.64s ( 0.64s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.66s ( 0.64s elapsed) %GC time 0.0% (0.1% elapsed) Alloc rate 51,495,642 bytes per MUT second Productivity 100.0% of total user, 102.3% of total elapsed }}} Looking at the ASM dump for the innermost tight culling loop reveals the problem, with 7.8.1 RC2 outputting as follow: {{{ _n3nx: movl 76(%esp),%ecx _c3gf: cmpl %ecx,%eax jg _c3jB _c3jC: movl %eax,%edx sarl $5,%edx movl %ecx,76(%esp) movl $1,%ecx movl %ecx,280(%esp) movl %eax,%ecx andl $31,%ecx movl %eax,292(%esp) movl 280(%esp),%eax shll %cl,%eax xorl $-1,%eax movl 64(%esp),%ecx addl $8,%ecx movl (%ecx,%edx,4),%ecx andl %eax,%ecx movl 64(%esp),%eax addl $8,%eax movl %ecx,(%eax,%edx,4) movl 292(%esp),%eax addl $3,%eax jmp _n3nx }}} and 7.6.3 outputting as follows: {{{ .text .align 4,0x90 .long 1894 .long 32 s1GZ_info: _c1YB: cmpl 16(%ebp),%esi jg _c1YE movl %esi,%edx sarl $5,%edx movl $1,%eax movl %esi,%ecx andl $31,%ecx shll %cl,%eax xorl $-1,%eax movl 12(%ebp),%ecx movl 8(%ecx,%edx,4),%ecx andl %eax,%ecx movl 12(%ebp),%eax movl %ecx,8(%eax,%edx,4) addl 4(%ebp),%esi jmp s1GZ_info _c1YE: movl 8(%ebp),%esi addl $8,%ebp jmp s1GB_info }}} The second code is clearly much more efficient, with the only memory access reading/writing the sieve buffer array and one register reload of the prime value to add to the current position index, whereas the first (7.8.1 RC2) code has three register spills and five register re-loads, almost as if debugging were still turned on. This bug was tested under Windows, but likely applies to other platforms, at least for 32-bit versions but also possibly to others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 03:40:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 03:40:43 -0000 Subject: [GHC] #8958: Allow role inference on datatype contexts In-Reply-To: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> References: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> Message-ID: <062.8c91eb1e08fdb7bca2618bbd223062a5@haskell.org> #8958: Allow role inference on datatype contexts -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | goldfire Priority: normal | Status: closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: roles/should_compile/T8958 | Architecture: Blocking: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: The code in the original post is indeed a grievous hack, but the change in GHC in order to support it is not. Indeed, when Mark first suggested this approach, I thought it was too unprincipled to incorporate. However, the only change needed within GHC to support the idea in the original post is that role inference must look at datatype contexts. This is sensible, all on its own. In fact, the user manual, as originally written for role inference, needs no change: it states that role inference propagates role information from every place a type is used, which naturally includes a datatype context. Now with this support in GHC, the grievous hack in my original post can be built in user-land. I have released it as a package `no-role-annots`. I don't really like it, but it seems to cause no harm and some might find it useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 07:52:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 07:52:42 -0000 Subject: [GHC] #8958: Allow role inference on datatype contexts In-Reply-To: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> References: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> Message-ID: <062.adaaf41c967d4f14e15957907c96239b@haskell.org> #8958: Allow role inference on datatype contexts -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | goldfire Priority: normal | Status: closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: roles/should_compile/T8958 | Architecture: Blocking: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Comment (by simonpj): Fair enough. You are arguing that nothing belongs in the user manual because there is no special compiler behaviour. Yet a user approaching roles might still miss all of this. We have a mechanism for this: a wike page at Haskell.org. The "Documentation" link on [http://www.haskell.org/ghc/ GHC's home page] gets you [http://www.haskell.org/haskellwiki/GHC here]. The "Collaborative documentation" section is for user-level documentation about how to use GHC, above and beyond the user manual. In particular there is user-level documentation for [http://www.haskell.org/haskellwiki/GHC/Type_system type system extensions]. So that would be an excellent place for some user- facing documentation about roles, including a pointer to your library. I'm not suggesting that it's your responsibility to write such a page; but starting one, with an invitation to others to add more, would be an excellent move. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 08:08:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 08:08:40 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.da6ddebf5f8a0414c1c1c3c04a52a004@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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): * cc: simonmar (added) * component: Compiler => Compiler (NCG) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 08:27:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 08:27:32 -0000 Subject: [GHC] #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies In-Reply-To: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> References: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> Message-ID: <061.f11365dd3ca03136e7dc88acd7737380@haskell.org> #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies -------------------------------------------------+------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Yes, I think this is a long-outstanding bug, awaiting someone with some time and attention. See #6124 for example. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 08:43:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 08:43:29 -0000 Subject: [GHC] #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies In-Reply-To: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> References: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> Message-ID: <061.e23d4a91396e1e80acf6b04002866b12@haskell.org> #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies -------------------------------------------------+------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: #3927 | #6124 -------------------------------------------------+------------------------- Changes (by jstolarek): * related: => #3927 #6124 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 08:43:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 08:43:40 -0000 Subject: [GHC] #8966: Pattern synonyms and kind-polymorphism In-Reply-To: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> References: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> Message-ID: <062.f0258ef56d2ba8bc6902a1ddd872e9d2@haskell.org> #8966: Pattern synonyms and kind-polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4dc9f9869bfc82fdb8bd61864859007873ebcc27/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4dc9f9869bfc82fdb8bd61864859007873ebcc27" Zonk the existential type variables in tcPatSynDecl This was just an omission, which showed up as Trac #8966 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 08:50:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 08:50:03 -0000 Subject: [GHC] #8966: Pattern synonyms and kind-polymorphism In-Reply-To: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> References: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> Message-ID: <062.626c0975049d25a420aeaaa922b8019d@haskell.org> #8966: Pattern synonyms and kind-polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: simonpj Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: patsyn/T8966 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: new => merge * testcase: => patsyn/T8966 Comment: Good catch, thank you. Please merge to 7.8 branch in due course. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 11:46:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 11:46:51 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.57e525f815e5d4b3a189e51241b62537@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 12:08:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 12:08:36 -0000 Subject: [GHC] #8963: GeneralizedNewtypeDeriving unusable on associated types In-Reply-To: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> References: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> Message-ID: <062.da0dbca0b4f4527160b466d5c56e4f38@haskell.org> #8963: GeneralizedNewtypeDeriving unusable on associated types -------------------------------------+------------------------------------ Reporter: mojojojo | 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 simonpj): * status: new => closed * resolution: => fixed Comment: Yes, it was indeed fixed some time ago. We don't back-port language changes to patch releases (in this case 7.6.3). But the fix is in 7.8 which will be out any day. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 12:13:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 12:13:32 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops Message-ID: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've received reports that using `IORef Int` and `atomicModifyIORef` to implement an atomic counter in the ekg package has become a bottleneck for some of its users. These users update the counter thousands of times per second, using multiple threads. I will investigate whether adding a dedicated atomic `Int` reference type will offer significant speed improvements. Such a type can also be used to implement cheaper locks (by using bits in the int to represent different lock states, such as reader/write locks.) Lets call this new type `AtomicIntRef` for now. This new type needs to support at least these functions: {{{#!haskell add :: AtomicIntRef -> Int -> IO Int set :: AtomicIntRef -> Int -> IO () get :: AtomicIntRef -> IO Int }}} `add` would be implemented using the `lock` and `xaddq` instructions. `set` and `get` are just simple loads and stores on x86, as these are atomic. We might also want to consider having other functions, such as a `cas`. Furthermore, there are subtleties with memory barriers that might motivate having barrier/barrier-less versions of some functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 12:50:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 12:50:48 -0000 Subject: [GHC] #8963: GeneralizedNewtypeDeriving unusable on associated types In-Reply-To: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> References: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> Message-ID: <062.56fce2ba84eee3379619d7000f0f2b19@haskell.org> #8963: GeneralizedNewtypeDeriving unusable on associated types -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by mojojojo): Oh great! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 12:59:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 12:59:46 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.10158b756ab3440dad6aec44d2235e7a@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * cc: cactus, dimitris@? (added) Comment: Harump. This is a real shortcoming in the pattern-synonym stuff. Consider {{{ data T a b where MkT :: a -> T a Bool MkX :: T a b pattern P = MkT True }}} What type should pattern P have? It could be {{{ P :: T Bool b or P :: T b b }}} Both would work, because pattern matching on `MkT` ensures that `b~Bool`. But neither is more general than the other. So GHC rejects it, with the (confusing) errors. {{{ T8968.hs:9:17: Couldn't match expected type ?t? with actual type ?Bool? ?t? is untouchable inside the constraints (t1 ~ Bool) bound by a pattern with constructor MkT :: forall a. a -> T a Bool, in a pattern synonym declaration at T8968.hs:9:13-20 ?t? is a rigid type variable bound by the inferred type of P :: T t t1 at T8968.hs:1:1 In the pattern: True In the pattern: MkT True T8968.hs:9:17: Could not deduce (t ~ Bool) from the context (t1 ~ Bool) bound by the type signature for T8968.$WP :: t1 ~ Bool => T t t1 at T8968.hs:9:9 ?t? is a rigid type variable bound by the type signature for T8968.$WP :: t1 ~ Bool => T t t1 at T8968.hs:1:1 Relevant bindings include $WP :: T t t1 (bound at T8968.hs:9:9) In the first argument of ?MkT?, namely ?True? In the expression: MkT True }}} (There are two errors, one `P` in matching and one for `P` in an expression. I think we can fix that part by failing earlier.) This ambiguity is the cause of the error kosmikus came across, I think. In the !OutsideIn algorithm we insist on a type signature for functions like this. My conclusion * We need signatures for pattern synonyms. Do such signatures exist yet? * Ideally we would find a more civilised way to reject such programs, perhaps suggesting a signature. But first, have I analysed this right. Copying Dimitrios. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 13:10:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 13:10:44 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.215f7ed9e1dfee89e987fcaab3ed3d3b@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): FWIW, I was assuming the problem that SPJ describes is the underlying problem here. I don't know the implementation, but I find it entirely reasonable that pattern synonyms for GADTs will in general require type signatures in order to disambiguate between incomparable types. That's why I started talking about type signatures for pattern synonyms in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 13:30:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 13:30:05 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.b12155af285b55723ff9aca05ac93196@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): I've added a little benchmark that shows that even calling out to C can speed things up a lot. Using `IORef`: {{{ $ ghc -O2 Bench.hs counter.c -DOLD=1 ... $ time ./Bench real 0m1.698s user 0m1.670s sys 0m0.020s }}} Calling out to C: {{{ $ ghc -O2 Bench.hs counter.c ... $ time ./Bench real 0m0.108s user 0m0.090s sys 0m0.010s }}} That's a ~16x speed-up. Things look similar with the threaded RTS: Using `IORef`: {{{ $ ghc -O2 Bench.hs counter.c -DOLD=1 -threaded ... $ time ./Bench real 0m1.998s user 0m1.980s sys 0m0.010s }}} Calling out to C: {{{ $ ghc -O2 Bench.hs counter.c -threaded $ time ./Bench real 0m0.117s user 0m0.100s sys 0m0.010s }}} With `+RTS -N6` (real hardware cores on the test machine): Using `IORef`: {{{ $ time ./Bench +RTS -N6 real 1m22.565s user 1m23.850s sys 1m11.240s }}} Calling out to C: {{{ $ time ./Bench +RTS -N6 real 0m0.247s user 0m1.340s sys 0m0.010s }}} Atrocious results for the `IORef` solution! It seems like contended `IORef`s don't work well at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 13:38:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 13:38:42 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.1935e4d90c72da43bddcc1b8252e0576@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by cactus): We don't have frontend support for pattern synonym signatures (see #8584). However, this can be worked around using the technique described in #8584, so I was able to get your code to typecheck by modifying it as: {{{ {-# LANGUAGE GADTs, KindSignatures, PatternSynonyms, ScopedTypeVariables #-} data X :: (* -> *) -> * -> * where Y :: f Int -> X f Int pattern C x = (Y (Just x) :: X Maybe Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 13:39:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 13:39:54 -0000 Subject: [GHC] #8584: Pattern synonym type signatures In-Reply-To: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> References: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> Message-ID: <060.ad2f71fdd9e64defc7f9f99f391e0167@haskell.org> #8584: Pattern synonym type signatures -------------------------------------+------------------------------------ Reporter: cactus | 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: 5144 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by cactus): It is not dead, just dormant :) Haddock uses it. The plan for this ticket is to add frontend (parser/typechecker) support for `PatSynSig`, but it's not done yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 13:47:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 13:47:24 -0000 Subject: [GHC] #8961: Require PatternSynonyms language extension to *use* pattern synonyms In-Reply-To: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> References: <045.7eb543ae8f9023b06b3f788ae122e701@haskell.org> Message-ID: <060.dfdd0fc9d8643fa03ec8e6124cab2233@haskell.org> #8961: Require PatternSynonyms language extension to *use* pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc2 checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by cactus): I did this because I thought requiring the language pragma at use sites is the more conservative choice, given that `PatternSynonyms` is more of a tech preview than a full feature yet (see #8581, #8582, #8583, #8779 for some of the missing features from the original proposal; #8584 and #8761 for more pressing issues, #8968 for a potentially deeper rabbit hole). If that is the consensus, I have no problems with reverting this, but I think for 7.8.1 we should leave this in so that it requires effort (and thus it cannot go unnoticed) if you use this feature. A future release with the above-mentioned problems addressed could then remove this hoop to jump through. So my vote is on keeping this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 13:56:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 13:56:25 -0000 Subject: [GHC] #7068: Extensive Memory usage (regression) In-Reply-To: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> References: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> Message-ID: <063.df1553afd090d7fc174025cc599ef995@haskell.org> #7068: Extensive Memory usage (regression) -------------------------------------------------+------------------------- Reporter: waldheinz | Owner: Type: bug | simonpj Priority: high | Status: new Component: Compiler | Milestone: 7.8.1 Resolution: | Version: 7.4.1 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nh2): pcapriotti's Vec example doesn't seem to blow up for me on 7.6.3 Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 14:05:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 14:05:32 -0000 Subject: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? In-Reply-To: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> References: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> Message-ID: <060.570c6ef8922a559ccd64df41459ee3b4@haskell.org> #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by carter): * version: 7.7 => 7.9 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 14:12:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 14:12:33 -0000 Subject: [GHC] #8973: Fewer CPSZ: lines with -dshow-passes Message-ID: <046.f2d0f40d983e764406f283f1eadeeb66@haskell.org> #8973: Fewer CPSZ: lines with -dshow-passes ------------------------------------+------------------------------------- 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: | ------------------------------------+------------------------------------- `-dshow-passes` generates {{{ *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** Assembler: }}} All those CPSZ things are not helping! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 14:12:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 14:12:40 -0000 Subject: [GHC] #8973: Fewer CPSZ: lines with -dshow-passes In-Reply-To: <046.f2d0f40d983e764406f283f1eadeeb66@haskell.org> References: <046.f2d0f40d983e764406f283f1eadeeb66@haskell.org> Message-ID: <061.45b2c0f4d3d25b6dd787fc59336a9548@haskell.org> #8973: Fewer CPSZ: lines with -dshow-passes -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonmar 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 simonpj): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 14:21:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 14:21:24 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.f114611e996339b9b0e14ff2a648ddbd@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8157,7883 -------------------------------------+------------------------------------ Changes (by carter): * related: => 8157,7883 Comment: unboxed references! Yes, that'd be a good idea. Related tickets are #8157 and #7883 now that 7.8 is cut, i can take some time to work on #7883 and have some hope for getting it merged in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 14:22:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 14:22:02 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.d34dd06561b8ca92d9462bb8089cc5c7@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8157, 7883 -------------------------------------+------------------------------------ Changes (by carter): * related: 8157,7883 => 8157, 7883 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 15:34:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 15:34:10 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.a52e5c22ecae7a4d75b78040222a731e@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): Thanks. This is actually helping. However, it doesn't seem to work all the time. Consider this small variation of my program above: {{{ {-# LANGUAGE GADTs, KindSignatures, PatternSynonyms, ScopedTypeVariables #-} data X :: (* -> *) -> * -> * where Y :: f a -> X f (Maybe a) -- pattern C :: a -> X Maybe (Maybe a) pattern C x = Y (Just x) :: X Maybe (Maybe a) }}} The `a` variable in the type signature cannot be quantified, because it's the type of `x`. I don't seem to be able to give a type signature to `x` on the LHS. The attempt as given above results in an internal error: {{{ PatKind.hs:7:44: GHC internal error: ?a? is not in scope during type checking, but it passed the renamer tcl_env of environment: [(a5PN, Identifier[x::a, ])] In an expression type signature: X Maybe (Maybe a) In the expression: Y (Just x) :: X Maybe (Maybe a) In an equation for ?$WC?: ($WC) x = Y (Just x) :: X Maybe (Maybe a) }}} Any further ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 15:35:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 15:35:20 -0000 Subject: [GHC] #8115: GHC 64-bit Windows build failures with LLVM In-Reply-To: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> References: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> Message-ID: <061.89550bd5f81daba59820d69331b12aa2@haskell.org> #8115: GHC 64-bit Windows build failures with LLVM ---------------------------------+------------------------------------ Reporter: schyler | Owner: Type: bug | Status: new Priority: highest | 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: ---------------------------------+------------------------------------ Comment (by awson): 7.8.1 suffers from #7143. Workaround `-pgmlo opt -pgmlc llc` works, but executable produced by 64-bit 7.8.1 from the following code: {{{ import System.Mem (performMajorGC) main = performMajorGC >> putStrLn "Done" }}} segfaults. Switching off optimization does not help. Switching between LLVM 3.4 and 3.5svn does not help either. Executable produced by 32-bit 7.8.1 works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 15:59:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 15:59:09 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults Message-ID: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+---------------------------------- {{{ -- test.hs import System.Mem (performMajorGC) main = performMajorGC >> putStrLn "Done" }}} built with `ghc -pgmlo opt -pgmlc llc -fllvm --make test.hs` segfaults both for LLVM 3.4 and 3.5svn (taken from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64). 32-bit ghc-7.9.20140404+llvm produces good executable. Adding `ArchX86_64` `OSMinGW32` case to `moduleLayout` in `compiler/llvmGen/LlvmCodeGen/Ppr.hs` improves things slightly (some code segfaulting without it starts to work) but still does not cure the code above. Also I've found the Cmm produced for LLVM CG differs from that produced for NCG. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 16:21:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 16:21:14 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.b4901e3bf0bb0fa1c9125f409dd5f07a@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by carter): CMM is generated *before* the NCG and LLVM backends... so is there some code path before the code gen that depends on which code gen is selected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 16:38:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 16:38:08 -0000 Subject: [GHC] #8963: GeneralizedNewtypeDeriving unusable on associated types In-Reply-To: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> References: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> Message-ID: <062.c6f592bae32fba1d63061c2e9f8c2e2c@haskell.org> #8963: GeneralizedNewtypeDeriving unusable on associated types -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"848f595266268f578480ceb4ab1ce4938611c97e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="848f595266268f578480ceb4ab1ce4938611c97e" Allow a longer demand signature than arity See Note [Demand analysis for trivial right-hand sides] in DmdAnal. This allows a function with arity 2 to have a DmdSig with 3 args; which in turn had a knock-on effect, which showed up in the test for Trac #8963. In fact it seems entirely reasonable, so this patch removes the WARN and CoreLint checks that were complaining. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 16:38:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 16:38:09 -0000 Subject: [GHC] #8963: GeneralizedNewtypeDeriving unusable on associated types In-Reply-To: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> References: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> Message-ID: <062.8dec9ef777211d7a82e33e4606b047e7@haskell.org> #8963: GeneralizedNewtypeDeriving unusable on associated types -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"cc3ccf9f47c7f4684cdd2b08d0e2acf50b69bc18/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cc3ccf9f47c7f4684cdd2b08d0e2acf50b69bc18" Test Trac #8963 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 16:38:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 16:38:10 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.364a91d10b871422ca8d106d0862c200@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"50bfd4219157473fac47c70993fc2023a162a7f3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="50bfd4219157473fac47c70993fc2023a162a7f3" Improve error reporting for untouchable type variables This change adds a suggestion Possible fix: add a type signature for ?f? when we have a GADT-style definition with a type we can't figure out. See Note [Suggest adding a type signature] in TcErrors. This initially came up in the discussion of Trac #8968. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 18:28:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 18:28:44 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.3a5a8b60ed23ab42715b94010e0556fb@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): After thinking about this some more, I'm getting more confused. How should pattern matching on these pattern synonyms work? Both `P` in SPJ's example and `C` in my examples are bidirectional pattern synonyms, and as an expression, it should be easy enough for GHC to type-check without a type signature. So why require one in this case? The expression type signature and pattern type signature must be the same, after all. (Even for unidirectional ones, I'd argue that probably inferring a type for the pattern itself shouldn't be too difficult.) The main question is whether such synonyms can then be used in order to trigger type refinement. It currently seems they cannot, no matter what type they have. For my original example, consider this: {{{ {-# LANGUAGE GADTs, KindSignatures, PatternSynonyms, ScopedTypeVariables #-} data X :: (* -> *) -> * -> * where Y :: f Int -> X f Int pattern C x = Y (Just x) :: X Maybe Int f :: X Maybe a -> a f (Y (Just x)) = x -- works f (C x) = x -- fails }}} For Simon's example, consider: {{{ {-# LANGUAGE GADTs, PatternSynonyms, ScopedTypeVariables, RankNTypes #-} data T a b where MkT :: a -> T a Bool MkX :: T a b Q1 :: T Bool Bool Q2 :: T Bool b Q3 :: T b Bool Q4 :: T b b pattern P1 = MkT True :: T Bool Bool pattern P1a <- MkT True :: T Bool Bool pattern P2a <- MkT True :: forall b. T Bool b pattern P3a <- MkT True :: forall b. T b Bool pattern P4a <- MkT True :: forall b. T b b f :: T Bool b -> Bool f (MkT True) = True -- works f Q1 = True -- works f Q2 = undefined -- works f Q3 = True -- works f Q4 = True -- works f P1 = True -- fails f P1a = True -- fails f P2a = undefined -- fails f P3a = True -- fails f P4a = True -- fails }}} Is it unreasonable to expect this kind of thing to work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 18:36:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 18:36:32 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" In-Reply-To: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> References: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> Message-ID: <061.44fc270d61e9595f6d9eef825cded842@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" -------------------------------+----------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: arm ghci Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+----------------------------- Comment (by AriePeterson): Replying to [comment:3 Ansible]: > Here's my build of ghc on the PI: > [...] For reference, I tried to use your build on my rpi, under Raspbian, with some success. Ghci doesn't work though (the illegal instruction error even occurs one package earlier, when linking integer-gmp). I compiled quite a few packages succesfully. However, installing vector-0.10.9.1 fails: when compiling the module Data.Vector.Fusion.Stream.Monadic, ghc tries to link in the integer-gmp package, and this fails. This reminds me of #8212. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 21:15:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 21:15:13 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" In-Reply-To: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> References: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> Message-ID: <061.db57b09d931b12c5e6be8be2428f8188@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" -------------------------------+----------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: arm ghci Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+----------------------------- Comment (by Ansible): Well glad you've gotten some use out of it, even if its not 100% success. FWIW I've been able to use 7.6.3 under Arch linux on a 'wandboard' arm computer, and there ghci works. I didn't build ghc there, just installed it with pacman. I might give 7.8 a try on that machine, since it should be able to compile it (2G ram). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 8 21:54:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Apr 2014 21:54:58 -0000 Subject: [GHC] #8975: Troubling build warning with GHC 7.8.1 on Mavericks Message-ID: <050.6c30c380c8c9fe6f1e3c389f821c0db6@haskell.org> #8975: Troubling build warning with GHC 7.8.1 on Mavericks ----------------------------------+------------------------------ Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------ When building with gcc 4.8, I see this non-fatal error in the build log: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name time-1.4.2 -hide-all-packages -i -ilibraries/time/. -ilibraries/time/dist-install/build -ilibraries/time/dist- install/build/autogen -Ilibraries/time/dist-install/build -Ilibraries/time /dist-install/build/autogen -Ilibraries/time/include -optP- DLANGUAGE_Rank2Types -optP-DLANGUAGE_DeriveDataTypeable -optP- DLANGUAGE_StandaloneDeriving -optP-include -optPlibraries/time/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package deepseq-1.3.0.2 -package old-locale-1.0.0.6 -Wall -XHaskell2010 -XCPP -XRank2Types -XDeriveDataTypeable -XStandaloneDeriving -O2 -no-user- package-db -rtsopts -odir libraries/time/dist-install/build -hidir libraries/time/dist-install/build -stubdir libraries/time/dist- install/build -split-objs -dynamic-too -c libraries/time/./Data/Time/Calendar/Days.hs -o libraries/time/dist- install/build/Data/Time/Calendar/Days.o -dyno libraries/time/dist- install/build/Data/Time/Calendar/Days.dyn_o /usr/local/src/ghc-7.8.1/libraries/base/dist- install/build/Data/Typeable/Internal.hi Declaration for mkTyConApp Unfolding of Data.Typeable.Internal.mkTyConApp: Failed to load interface for ?GHC.Fingerprint? There are files missing in the ?base? package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name time-1.4.2 -hide-all-packages -i -ilibraries/time/. -ilibraries/time/dist-install/build -ilibraries/time/dist- install/build/autogen -Ilibraries/time/dist-install/build -Ilibraries/time /dist-install/build/autogen -Ilibraries/time/include -optP- DLANGUAGE_Rank2Types -optP-DLANGUAGE_DeriveDataTypeable -optP- DLANGUAGE_StandaloneDeriving -optP-include -optPlibraries/time/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package deepseq-1.3.0.2 -package old-locale-1.0.0.6 -Wall -XHaskell2010 -XCPP -XRank2Types -XDeriveDataTypeable -XStandaloneDeriving -O2 -no-user- package-db -rtsopts -odir libraries/time/dist-install/build -hidir libraries/time/dist-install/build -stubdir libraries/time/dist- install/build -split-objs -dynamic-too -c libraries/time/./Data/Time/Clock/Scale.hs -o libraries/time/dist- install/build/Data/Time/Clock/Scale.o -dyno libraries/time/dist- install/build/Data/Time/Clock/Scale.dyn_o /usr/local/src/ghc-7.8.1/libraries/base/dist- install/build/Data/Typeable/Internal.hi Declaration for mkTyConApp Unfolding of Data.Typeable.Internal.mkTyConApp: Failed to load interface for ?GHC.Fingerprint? There are files missing in the ?base? package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name time-1.4.2 -hide-all-packages -i -ilibraries/time/. -ilibraries/time/dist-install/build -ilibraries/time/dist- install/build/autogen -Ilibraries/time/dist-install/build -Ilibraries/time /dist-install/build/autogen -Ilibraries/time/include -optP- DLANGUAGE_Rank2Types -optP-DLANGUAGE_DeriveDataTypeable -optP- DLANGUAGE_StandaloneDeriving -optP-include -optPlibraries/time/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package deepseq-1.3.0.2 -package old-locale-1.0.0.6 -Wall -XHaskell2010 -XCPP -XRank2Types -XDeriveDataTypeable -XStandaloneDeriving -O2 -no-user- package-db -rtsopts -odir libraries/time/dist-install/build -hidir libraries/time/dist-install/build -stubdir libraries/time/dist- install/build -split-objs -dynamic-too -c libraries/time/./Data/Time/Clock/UTC.hs -o libraries/time/dist- install/build/Data/Time/Clock/UTC.o -dyno libraries/time/dist- install/build/Data/Time/Clock/UTC.dyn_o }}} I don't know if this is actually a problem or not, but since it doesn't cause make to fail, it possible that it may not have been noticed yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 05:58:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 05:58:54 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.b3aec994d690a4af6395b2cbfd781a13@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by kgardas): Hi, I've needed to use 0001-do-not-confuse-configure-by-a-bash- shell.patch? while building Solaris 10 7.8.1 binary distribution. So it works for me here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 07:26:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 07:26:43 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.42e5e2558f28723db6543a97d4c59636@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by ezyang): I grepped for other instances of SHELL configure being used, and found one: {{{ ezyang at sabre:~/Dev/ghc-clean$ ag "SHELL" libffi/ghc.mk 92: "$(SHELL)" ./configure \ }}} Does libffi also need to get updated? (Also, there is commented out to-do code which should also get fixed up). While I'm not too happy about the lack of explanation why it should be dropped, it's pretty weird that we were doing it that way in the first place, and `git gui blame` suggests the SHELL command has been around since the very beginning, so if this passes validation on all platforms, I think we should just take it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 07:39:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 07:39:46 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.041f15144fc382f5f21dfb82ce9993c5@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by ezyang): It would be helpful if you could post the C-- produced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 07:41:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 07:41:47 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.e1aa382ff6ec678da5e195d4df32ba96@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Changes (by ezyang): * cc: dterei (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 07:51:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 07:51:37 -0000 Subject: [GHC] #8973: Fewer CPSZ: lines with -dshow-passes In-Reply-To: <046.f2d0f40d983e764406f283f1eadeeb66@haskell.org> References: <046.f2d0f40d983e764406f283f1eadeeb66@haskell.org> Message-ID: <061.771b5deaae79d169a497cc4112026fcf@haskell.org> #8973: Fewer CPSZ: lines with -dshow-passes -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonmar 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 ezyang): The cause is we're running mapAccumL, calling the CPSZ pass on each `CmmGroup` in the stream. The obvious thing is to hoist the print out, but the tradeoff is now your debug output when you dump C-- no longer has demarcation markers: {{{ *** CPSZ: ==================== Post CPS Cmm ==================== ... ==================== Output Cmm ==================== ... ==================== Cmm produced by new codegen ==================== ... *** CPSZ: ==================== Post CPS Cmm ==================== ... ==================== Output Cmm ==================== ... ==================== Cmm produced by new codegen ==================== ... }}} Maybe we can do something more clever, or maybe it's OK to not have things partitioned up this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 08:01:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 08:01:21 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.3d04337414fd0aafe286851105c51f9e@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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): Doesn't seem to be a problem on 64-bit: {{{ .Lc4cz: cmpq %r8,%rbx jg .Lc4cJ .Lc4cK: movq %rbx,%rdx sarq $6,%rdx movl $1,%edi movq %rcx,%r9 movq %rbx,%rcx andq $63,%rcx shlq %cl,%rdi xorq $-1,%rdi leaq 16(%rax),%rcx movq (%rcx,%rdx,8),%rcx andq %rdi,%rcx leaq 16(%rax),%rdi movq %rcx,(%rdi,%rdx,8) addq %r9,%rbx .Ln4g8: movq %r9,%rcx jmp .Lc4cz }}} What happens if you use `-freg-graph`? If you could post C-- dumps that would also be helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 08:18:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 08:18:14 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.9372e41d3a41ec3d66585f1ac2f5b535@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): To make Cmm shorter I've separated segfaulting code from `main` (it still segfaults when called from `main`) thus: {{{ -- T8947.hs module T8947 where import System.Mem (performMajorGC) t8947 :: IO () t8947 = performMajorGC >> putStrLn "Done" }}} `T8947_LLVMCG_cmm` `T8947.ll` are produced by `ghc -O2 -pgmlo opt -pgmlc llc -fllvm -keep-llvm-files -ddump-cmm -c T8947.hs > T8947_LLVMCG_cmm`. `T8947_NCG_cmm` is produced by `ghc -O2 -ddump-cmm -c T8947.hs > T8947_NCG_cmm`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 08:19:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 08:19:11 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.e800b1d41a2dc7aeedcc3ee47e8053e9@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by maeder): This spot did not matter under (my) Solaris 10. In fact, ./configure is called twice: {{{ ... mv libffi/build/ltmain.sh libffi/build/ltmain.sh.orig sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < libffi/build/ltmain.sh.orig > libffi/build/ltmain.sh cd libffi && \ \ cd build && \ CC=/opt/csw/bin/gcc \ LD=/usr/ccs/bin/ld \ AR=/usr/ccs/bin/ar \ NM=/usr/ccs/bin/nm \ RANLIB=/usr/ccs/bin/ranlib \ CFLAGS=" -U__i686 -fno-stack-protector -w" \ LDFLAGS=" -w" \ "/bin/bash" ./configure \ --prefix=/local/home/maeder/haskell/ghc-7.8.1/libffi/build/inst \ --libdir=/local/home/maeder/haskell/ghc-7.8.1/libffi/build/inst/lib \ --enable-static=yes \ --enable-shared=no \ --host=i386-unknown-solaris2 configure: WARNING: if you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used checking build system type... i386-pc-solaris2.10 checking host system type... i386-unknown-solaris2 checking target system type... i386-unknown-solaris2 continue configure in default builddir "./i386-unknown-solaris2" ....exec /bin/sh .././configure "--srcdir=.." "--enable-builddir=i386 -unknown-solaris2" "solaris2" configure: WARNING: if you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used checking build system type... i386-pc-solaris2.10 checking host system type... i386-unknown-solaris2 checking target system type... i386-unknown-solaris2 ... }}} And finally config.status contains '/bin/bash'. (I'm now trying without "$(SHELL)" in libffi/ghc-mk.) (After all, for most purposes it does not matter if /bin/sh or /bin/bash is used.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 08:20:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 08:20:16 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 Message-ID: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 -------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------+---------------------------------------- ghc-7.8.1 fails to build on Fedora ARM. This appears to be a regression compared to 7.8.1 RC2. {{{ : chmod +x inplace/bin/runghc inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.1 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted }}} This is the bug report! This happens on both Fedora 20 (current latest stable release) and 21 (in development). The build is against ghc-7.6.3 and llvm 3.3 and 3.4 respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 08:21:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 08:21:32 -0000 Subject: [GHC] #8977: GHC infinite loop on Solaris Message-ID: <046.13b621cf13f34e2cdfa5dc435aa4e508@haskell.org> #8977: GHC infinite loop on Solaris ------------------------------------+--------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Solaris Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Hello, sometimes on Solaris ghc gets into infinite loop while trying to print something. E.g. ghc --version or ghc --info are good examples. This also happens for example while trying to build another ghc by already installed ghc. The reason for loop is simple: ghc is using libiconv for printing and libiconv is using its own libraries/binary tables. The problem arise when libiconv is not able to find the appropriate library/table file, then it tries to print error message (or GHC itself) which results in calling libiconv for printing which goes to search for appropriate library/table file and loop is closed. Please note that library/table file is different for different LANG settings. That also means that if you are able to invoke ghc --version on command line, still your ./configure of a new ghc may stuck on checking ghc version since configure sets LANG=C while on command line you may have LANG=en_US.UTF-8. Running ghc --version in truss shows this issue nicely as: {{{ /1: munmap(0xFF210000, 8790) = 0 /1: access("/usr/lib/iconv/geniconvtbl/binarytables/646%UTF-32BE.bt", R_OK) Err#2 ENOENT /1: access("/usr/lib/iconv/646%UTF-32BE.so", R_OK) Err#2 ENOENT /1: lwp_unpark(2) = 0 /2: lwp_park(0x00000000, 0) = 0 /2: clock_gettime(4, 0xFF0D9E68) = 0 /2: lwp_unpark(1) = 0 /1: lwp_park(0x00000000, 0) = 0 /1: access("/usr/lib/iconv/geniconvtbl/binarytables/646%UTF-32BE.bt", R_OK) Err#2 ENOENT /1: access("/usr/lib/iconv/646%UTF-32BE.so", R_OK) Err#2 ENOENT /1: open("/usr/lib/iconv/alias", O_RDONLY) = 7 /1: fstat64(7, 0xFFBFD388) = 0 /1: fstat64(7, 0xFFBFD5C8) = 0 /1: mmap(0x00000000, 8790, PROT_READ, MAP_SHARED, 7, 0) = 0xFF210000 /1: close(7) = 0 /1: munmap(0xFF210000, 8790) = 0 /1: access("/usr/lib/iconv/geniconvtbl/binarytables/646%UTF-32BE.bt", R_OK) Err#2 ENOENT /1: access("/usr/lib/iconv/646%UTF-32BE.so", R_OK) Err#2 ENOENT /1: access("/usr/lib/iconv/geniconvtbl/binarytables/646%UTF-32BE.bt", R_OK) Err#2 ENOENT /1: access("/usr/lib/iconv/646%UTF-32BE.so", R_OK) Err#2 ENOENT /1: open("/usr/lib/iconv/alias", O_RDONLY) = 7 /1: fstat64(7, 0xFFBFD388) = 0 /1: fstat64(7, 0xFFBFD5C8) = 0 }}} So, the solution on Solaris is simple. Install appropriate libiconv files. Usually if you are hit by this issue, then at least on Solaris 11 you are missing unicode-core package and this may be installed by: {{{ # pkg install unicode-core }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 08:23:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 08:23:01 -0000 Subject: [GHC] #8977: GHC infinite loop on Solaris In-Reply-To: <046.13b621cf13f34e2cdfa5dc435aa4e508@haskell.org> References: <046.13b621cf13f34e2cdfa5dc435aa4e508@haskell.org> Message-ID: <061.a60e06445f6c73c6ac92e6bbd7e781f0@haskell.org> #8977: GHC infinite loop on Solaris ---------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Resolution: wontfix | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by kgardas): * status: new => closed * resolution: => wontfix Comment: I'm closing since this was merely for documentation purposes. Hopefully google find it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 08:28:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 08:28:39 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.67045002d1582756cbef64957d2e67bb@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): Perhaps it would be interesting: `performMajorGC` alone and `putStrLn "Done"` alone works. `putStrLn "Done" >> performMajorGC` works. And {{{ foreign import ccall unsafe puts :: Ptr a -> IO () performMajorGC >> puts (Ptr "Done"#) }}} works too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 08:58:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 08:58:28 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.0c94a99684a2819f6c5b85114f48764a@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by maeder): It works without "$(SHELL)", too: {{{ ... mv libffi/build/ltmain.sh libffi/build/ltmain.sh.orig sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < libffi/build/ltmain.sh.orig > libffi/build/ltmain.sh cd libffi && \ \ cd build && \ CC=/opt/csw/bin/gcc \ LD=/usr/ccs/bin/ld \ AR=/usr/ccs/bin/ar \ NM=/usr/ccs/bin/nm \ RANLIB=/usr/ccs/bin/ranlib \ CFLAGS=" -U__i686 -fno-stack-protector -w" \ LDFLAGS=" -w" \ ./configure \ --prefix=/local/home/maeder/haskell/ghc-7.8.1/libffi/build/inst \ --libdir=/local/home/maeder/haskell/ghc-7.8.1/libffi/build/inst/lib \ --enable-static=yes \ --enable-shared=no \ --host=i386-unknown-solaris2 configure: WARNING: if you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used checking build system type... i386-pc-solaris2.10 checking host system type... i386-unknown-solaris2 checking target system type... i386-unknown-solaris2 continue configure in default builddir "./i386-unknown-solaris2" ....exec /bin/bash .././configure "--srcdir=.." "--enable-builddir=i386 -unknown-solaris2" "solaris2" configure: WARNING: if you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used checking build system type... i386-pc-solaris2.10 checking host system type... i386-unknown-solaris2 checking target system type... i386-unknown-solaris2 ... }}} Note, that now "/bin/bash" is used in the second call (that is somehow part of libffi). Yet, libffi/build/i386-unknown-solaris2/config.status still contains: {{{ SHELL='/bin/bash' }}} (So maybe gmp's ./configure is actually less robust wrt to shell detection.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 09:05:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 09:05:32 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.162986a435217b909a29b51553809dd1@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by kgardas): Replying to [comment:35 maeder]: > Note, that now "/bin/bash" is used in the second call (that is somehow part of libffi). Yet, > libffi/build/i386-unknown-solaris2/config.status still contains: > > {{{ > SHELL='/bin/bash' > }}} > > (So maybe gmp's ./configure is actually less robust wrt to shell detection.) That's why I fought hard for actual issue identification. :-) Indeed, the issue may in gmp's configure itself. The question is if you'd like to identify it and submit patch upstream and just work-around it in ghc itself... As I said I don't like your first attempt with using /bin/sh ./configure -- but I think removing $(SHELL) (in your second attempt) should be ok. Well, still fixing the gmp's configure is probably the most clean of those solutions anyway. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 09:35:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 09:35:26 -0000 Subject: [GHC] #5435: GHCi linker should run constructors for linked libraries In-Reply-To: <046.8b82a36416a611e39b118853f0f9d2f0@haskell.org> References: <046.8b82a36416a611e39b118853f0f9d2f0@haskell.org> Message-ID: <061.df492985b9de4b13c4fe3dbb16ab005d@haskell.org> #5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by Edward Z. Yang ): In [changeset:"f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e" Fix #5435, adding new test config check_stdout. check_stdout(f) allows you to override the test framework's diff based output checking with another mechanism. f is a function which takes two arguments: the first is the filename containing the observed stdout, the second is the normaliser that would have been applied (in case you want to read, normalise, and then do something.) Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 09:37:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 09:37:48 -0000 Subject: [GHC] #8458: T5435_dyn_asm fails on x86_64 Linux In-Reply-To: <048.6da04b00f79d78287d314ac7b472c3f4@haskell.org> References: <048.6da04b00f79d78287d314ac7b472c3f4@haskell.org> Message-ID: <063.e7737fc650c8f75c066bf228b26d7c7a@haskell.org> #8458: T5435_dyn_asm fails on x86_64 Linux ------------------------------------------------+-------------------------- Reporter: jstolarek | Owner: ezyang Type: bug | Status: merge Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by ezyang): * status: new => merge Comment: {{{ commit f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e Author: Edward Z. Yang Date: Wed Apr 9 02:32:21 2014 -0700 Fix #5435, adding new test config check_stdout. check_stdout(f) allows you to override the test framework's diff based output checking with another mechanism. f is a function which takes two arguments: the first is the filename containing the observed stdout, the second is the normaliser that would have been applied (in case you want to read, normalise, and then do something.) Signed-off-by: Edward Z. Yang }}} Dunno if we ought to bother merging this into stable, I'll flag it merge just in case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 09:56:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 09:56:16 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.47b602941a0df832e79f339289a2f852@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 awson): I didn't go into details but it looks `-fregs-graph` doesn't help. 7.8.1-compiled exec is still much slower than 7.6.3-compiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 10:29:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 10:29:06 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.9c693f02711c4d4ce8c86c739ace484a@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by jstolarek): Replying to [comment:1 carter]: > CMM is generated *before* the NCG and LLVM backends... so is there some code path before the code gen that depends on which code gen is selected? [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/cmm/CmmPipeline.hs#L104 Yes, there is.] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 12:55:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 12:55:31 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.77cd2d9e00ba64b624edd2aafb94867a@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by maeder): I've looked into these two ./configure scripts. Calling {{{ /bin/bash ./configure }}} is different from calling a script containing {{{ #!/bin/bash ./configure }}} The former just interprets the contents of ./configure (ignoring the initial #!/bin/sh). Whereas the latter, like any direct call of ./configure on any shell, properly executes ./configure (which requests to be interpreted by /bin/sh). The toggling between /bin/bash and /bin/sh by ./configure seems to be normal behavior. Maybe by chance it does not happen (due to multiple invocations of itself) for the second internal call: {{{ eval /bin/bash .././configure "--srcdir=.." "--enable-builddir=i386 -unknown-solaris2" }}} So, it rather looks like an autoconf problem although "autoreconf" actually generates "eval $SHELL ..." (with a different message "....exec $SHELL"). I have (GNU Autoconf) 2.69. I could post a report to gmp-bugs at gmplib.org, though, as "/bin/bash ./configure" fails later on in mpn with "../libtool: bad substitution" also for the latest version gmp-6.0.0a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 15:02:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 15:02:34 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.91a188e2c664a5a6c758b9bf664cb576@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by maeder): I've sent emails to gmp-bugs at gmplib.org and bug-autoconf at gnu.org. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 16:17:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 16:17:50 -0000 Subject: [GHC] #8978: Type synonyms are not *exactly* synonyms Message-ID: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> #8978: Type synonyms are not *exactly* synonyms ----------------------------+---------------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- {{{ {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} type Syn a = Associated a class Eq (Associated a) => Foo a where type Associated a :: * foo :: a -> Syn a -> Bool instance Foo () where type Associated () = Int foo _ x = x == x }}} In 7.6.3 and 7.8.1-rc2, this file compiles. In 7.8.1 release, GHC produces this error: {{{ No instance for (Eq (Syn ())) arising from a use of ?==? In the expression: x == x In an equation for ?foo?: foo _ x = x == x In the instance declaration for ?Foo ()? }}} even though there is an Eq instance for Associated (), and Syn is just a type synonym. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 16:18:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 16:18:16 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely (was: Type synonyms are not *exactly* synonyms) In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.a4b4a04acd393fd016a87b045872f885@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: ----------------------------------------------+---------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 20:23:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 20:23:04 -0000 Subject: [GHC] #8979: matching type function application with type synonym application Message-ID: <046.a22c33c4afe933950ff7c1a4cc81ed30@haskell.org> #8979: matching type function application with type synonym application -------------------------------------------+------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- When compiling this module: {{{ {-# LANGUAGE TypeFamilies #-} type family F a type family G a type H a = G a newtype T0 a = Cons0 (F (G a)) newtype T1 a = Cons1 (F (H a)) f :: T0 Char -> T1 Char f (Cons0 a) = Cons1 a }}} I get the type error {{{ MatchTypeFunction.hs:12:21: Couldn't match expected type ?F (H Char)? with actual type ?F (G Char)? NB: ?F? is a type function, and may not be injective In the first argument of ?Cons1?, namely ?a? In the expression: Cons1 a }}} The code works with GHC-7.8 RC2 and GHC-7.4.2, but no longer with GHC-7.8.1. I guess there was some change in how deep GHC resolves type function application and type synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 20:23:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 20:23:42 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.b723097f069699e404ec36694f03adda@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: ----------------------------------------------+---------------------------- Changes (by goldfire): * cc: eir@? (added) Comment: I just got bit by this, too, on code that worked with 7.8.1 RC2. A perusal through a `-ddump-tc-trace` makes it look like something in the constraint solver, but I could be wrong. An easy workaround (if you wrote the type synonym) is to use a one- equation type family instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 20:25:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 20:25:26 -0000 Subject: [GHC] #8979: matching type function application with type synonym application In-Reply-To: <046.a22c33c4afe933950ff7c1a4cc81ed30@haskell.org> References: <046.a22c33c4afe933950ff7c1a4cc81ed30@haskell.org> Message-ID: <061.51b81e9a8978e3cdfe854f7eefa27b55@haskell.org> #8979: matching type function application with type synonym application --------------------------------------------+------------------------------ Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Lemming): It looks very similar to #8978. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 20:25:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 20:25:49 -0000 Subject: [GHC] #8979: matching type function application with type synonym application In-Reply-To: <046.a22c33c4afe933950ff7c1a4cc81ed30@haskell.org> References: <046.a22c33c4afe933950ff7c1a4cc81ed30@haskell.org> Message-ID: <061.d8d7f8b1ee7183285a53c762df87668b@haskell.org> #8979: matching type function application with type synonym application --------------------------------------------+------------------------------ Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Resolution: duplicate | 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: => duplicate Comment: Yes, I'm closing as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 20:28:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 20:28:54 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.50f417eb814272c5a4bce625a7ddfebd@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Could this be from 6ae678e31a5fdd3b0bd1f8613fe164012bb630f4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 20:29:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 20:29:46 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.5ecbd8adb2a13e148f2adbaaeb7bee36@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: ----------------------------------------------+---------------------------- Changes (by Lemming): * cc: ghc@? (added) Comment: You can find another example in #8979. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 20:38:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 20:38:32 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.58f169a36e6a22330495d4d4f5abc178@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Lemming): Replying to [comment:2 goldfire]: > An easy workaround (if you wrote the type synonym) is to use a one- equation type family instead. That helped. Thanks for the suggestion! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 20:42:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 20:42:03 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.0274fc8f28fc1a174b67ade965a19d54@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 joelteon): The single-equation solution fixes this particular problem, but this is a simplification of library code that's throwing this error now, in which the type family cannot be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 20:44:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 20:44:09 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.7022bf1fddf6954efb4fa3103a76f4d2@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): Sorry if I was unclear -- I meant to change the vanilla type synonym into a type family. My guess is that GHC won't care whether the new family is closed or open with one universal equation (if you need backward compatibility). You don't need to change the existing type family for my workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 21:13:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 21:13:20 -0000 Subject: [GHC] #8943: Add System.Process.createPipe In-Reply-To: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> References: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> Message-ID: <059.0c342f95ec1a66a9f5a4c3c08ae69969@haskell.org> #8943: Add System.Process.createPipe --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/process | 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): simonmar added this info to the discussion thread: > I seem to remember that on Windows there are subtleties to do with whether the pipe ends are inheritable by subprocesses or not. See mkAnonPipe() in the process package for how we deal with this already in process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 21:52:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 21:52:11 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.340354936e905661bcf063763ed4a750@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Ugh. This is my fault; an egregious blunder in a (cool) clean-up of the type flattener. It's easy to fix (patch coming) but the bug is in the released 7.8.1. Will fix in 7.8.2. It just shows, you never have enough regression tests! It affects any type synonym whose RHS mentions a type family. (Data families are fine.) Such as `Syn` above, or `H` in #8979. Richard's workaround is good; use a type family instead. Sorry about this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 22:24:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 22:24:31 -0000 Subject: [GHC] #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc-citeproc Message-ID: <045.b3bb12ede69a22b49498521b36f8f9a8@haskell.org> #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc- citeproc ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It's mostly a http://www.haskell.org/pipermail/ghc- devs/2014-March/004363.html rechecked on ghc-7.8.1: I attempted to leave original packages as-is. Steps to reproduce: {{{ $ cd /tmp/ $ wget -c http://code.haskell.org/~slyfox/selfcontained-eater- ghc-7.8-rc2.tar.gz $ tar -xzf selfcontained-eater-ghc-7.8-rc2.tar.gz $ cd selfcontained-eater-ghc-7.8-rc2 $ ./mk.sh ... [279 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting- kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting- kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) stack overflow: use +RTS -K to increase it }}} I did prepare this testcase for ghc-7.6.3 where it failed only on last 452 module. '''./mk.sh''' is a dumb script calling '''ghc -O2''' + cabal-generated bits. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 22:34:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 22:34:57 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.e305b24e2329f87cc2f24bef5a1febf6@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Lemming): Replying to [comment:8 simonpj]: > Ugh. This is my fault; an egregious blunder in a (cool) clean-up of the type flattener. It's easy to fix (patch coming) but the bug is in the released 7.8.1. Will fix in 7.8.2. It just shows, you never have enough regression tests! Will there be a "nightly snapshot build" for easy testing of the bugfix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 9 22:37:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Apr 2014 22:37:21 -0000 Subject: [GHC] #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 In-Reply-To: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> References: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> Message-ID: <064.eedb183b84bbedfe70ff8f7e4ab04ea9@haskell.org> #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 ---------------------------------------+----------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by slyfox): * cc: slyfox@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 01:15:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 01:15:44 -0000 Subject: [GHC] #8981: ghc-pkg complains about missing haddock interface files Message-ID: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> #8981: ghc-pkg complains about missing haddock interface files --------------------------+------------------------------------------------ Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.8.2 Priority: normal | Version: 7.8.1 Component: | Operating System: MacOS X Compiler | Type of failure: Incorrect result at runtime Keywords: ghc- | Test Case: pkg | Blocking: Architecture: x86_64 | (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ As Conal reported on the mailing list[1], `ghc-pkg check` on Mavericks allegedly returns: {{{ bash-3.2$ ghc-pkg check Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory }}} It's not fatal, but makes the output much more annoying. I figured this would have been caught by validate or somesuch, but apparently not. Marking for 7.8.2. I'm looking into this soon. [1]http://www.haskell.org/pipermail/glasgow-haskell- users/2014-April/024846.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 01:25:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 01:25:46 -0000 Subject: [GHC] #8981: ghc-pkg complains about missing haddock interface files In-Reply-To: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> References: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> Message-ID: <067.b4004d52fc386a98b30ce3e0083fc58c@haskell.org> #8981: ghc-pkg complains about missing haddock interface files ------------------------------------------------+-------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1 Resolution: | Keywords: ghc- Operating System: MacOS X | pkg Type of failure: Incorrect result at runtime | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by SimonHengel): * cc: sol@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 03:31:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 03:31:56 -0000 Subject: [GHC] #8976: dll-split: internal error: evacuate(static): strange closure type 0 In-Reply-To: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> References: <050.3f03921ecbab8dbcaa2aa5e8c2d08707@haskell.org> Message-ID: <065.9a8ec20723848e3990edf6b5eea53642@haskell.org> #8976: dll-split: internal error: evacuate(static): strange closure type 0 ----------------------------------------+--------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by juhpetersen): * component: Compiler => Driver * milestone: => 7.8.2 Comment: Karel pointed out this post by Ben on this topic: http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html (the short version being to use the gold linker). Austin suspects it started happening after RC2 because of https://github.com/ghc/ghc/commit/abb86adf7f749b3d44887d28bc96b43c5a1e0631 which presumably started the ARM build using dynamic linking. I guess it would be good to force the ARM build to use the gold linker for dyn linking, at least when the bfd linker is "broken". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 04:36:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 04:36:22 -0000 Subject: [GHC] #8982: Add Pertness to Your Rear With Buttlifter Slimming Message-ID: <045.0979f4f91591c2d8da36e97febeef8f8@haskell.org> #8982: Add Pertness to Your Rear With Buttlifter Slimming -------------------------------------+------------------------------------- Reporter: scydv1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (FFI) | Version: 6.5 Keywords: | Operating System: Irix Architecture: m68k | Type of failure: Installing GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- One of the most common "difficulty areas" we women surface is that dreaded lower intumesce jut or a not-as-toned-as-we'd equivalent face. This capital that act skirts and dresses, peculiarly those that are especially formfitting, are not the most pleasant or sureness boosting have. These garments incline to swing work to those difficulty areas, and too many times, the cutest dresses and skirts are the ones that pretense off that dimpled bum or swell imperfections the most. But before you depart yourself to a sentence without the latest fashions or those artful short drawing, learn out the capability of slimming nightwear on move. [http://try100puregarciniacambogia.com/ 100 Pure Garcinia Cambogia] You can flatten and deposition and give your stooge a actuation a slimming result, rule in unclaimed fat, and make a ingratiatory silhouette - are an surprising conception for us women who aren't perfect but would equal to be able to accentuate what we bang, and reduce from what we'd kinda not nidus on. With slimming nightwear, those formfitting skirts and dresses are no yearner an unattainable envisage. These undergarments are designed to be imperceptible - so nobody leave live you fuck a bit of service - but firmly regard in that tumefy fat, employ your laughingstock that good make, and pee those bed you a Brazilian goat rise, but without the expense. This implementation that you can assume that artful pencil touch or hot garb, and time wearing one of these undergarments you faculty not score throwaway bulges, dimples, or hump handles on pass, upright a unsubdivided, upturned, slimmed downward body regulate that is to die for. Now you can bear your skirts and dresses with certainty, and also be trusty that you can get the perfect undergarment for whatsoever you are act. Buttlifter Process undergarment oft comes in nasal wave forms, boy pants, or something a bit writer kindred to cycling trunks. This way that whether your skirt or fix is tangency or oblong, you can pronounce a unify that does what you condition, and fits with assist. Unlike word fabrication undergarments of the bypast, you can now incessant motion or bulging of these undergarments and you leave never feature to anxiety near anyone lettered you are act them. '''100 Pure Garcinia Cambogia''' Help your confidence and increase your make horizons with these buttlifter, tum flattening, and constructive undergarments. Don't be agoraphobic to don that clenched less sarcastic position on your incoming night out on the municipality with friends, and don't be hydrophobic of all day suffering as a outcome of act these undergarments for interminable periods of example. They are rich, employ incredibly shaft, are surprisingly cheap, and they present excrete http://try100puregarciniacambogia.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 06:17:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 06:17:33 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.0c662931762c061062795ebdeb4d6015@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 snoyberg): This bug has apparently broken a number of my packages, and I'm not certain if all of them can be fixed in a way that's backwards compatible with GHC 7.4 and 7.6 (both of which I still support). Would it be possible to release 7.8.2 with this fix alone, instead of waiting a number of months for the release as would normally be done? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:13:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:13:14 -0000 Subject: [GHC] #8958: Allow role inference on datatype contexts In-Reply-To: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> References: <047.555883f10d45ee1cedf6a05b70b3621c@haskell.org> Message-ID: <062.0993a76177f56b77d7053fb4fc7a84da@haskell.org> #8958: Allow role inference on datatype contexts -----------------------------------------------+--------------------------- Reporter: goldfire | Owner: Type: feature request | goldfire Priority: normal | Status: closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: roles/should_compile/T8958 | Architecture: Blocking: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b4dd5667fe84cb6030d296e9e4563d4de62f718d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b4dd5667fe84cb6030d296e9e4563d4de62f718d" Suppress uniques to stop output wobbling (test for Trac #8958) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:13:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:13:15 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.38f122f7fc19fd1e9dc3f73de503f035@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Simon Peyton Jones ): In [changeset:"b8132a9d2fdb93c5d30107b1d531dd73ac27b262/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b8132a9d2fdb93c5d30107b1d531dd73ac27b262" Fix egregious blunder in the type flattener In tidying up the flattener I introduced an error that no regression test caught, giving rise to Trac #8978, #8979. It shows up if you have a type synonym whose RHS mentions type functions, such sas type family F a type T a = (F a, a) -- This synonym isn't properly flattened The fix is easy, but sadly the bug is in the released GHC 7.8.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:13:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:13:15 -0000 Subject: [GHC] #8979: matching type function application with type synonym application In-Reply-To: <046.a22c33c4afe933950ff7c1a4cc81ed30@haskell.org> References: <046.a22c33c4afe933950ff7c1a4cc81ed30@haskell.org> Message-ID: <061.bb1c51f37c06f975f12580ed507d8e58@haskell.org> #8979: matching type function application with type synonym application --------------------------------------------+------------------------------ Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"b8132a9d2fdb93c5d30107b1d531dd73ac27b262/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b8132a9d2fdb93c5d30107b1d531dd73ac27b262" Fix egregious blunder in the type flattener In tidying up the flattener I introduced an error that no regression test caught, giving rise to Trac #8978, #8979. It shows up if you have a type synonym whose RHS mentions type functions, such sas type family F a type T a = (F a, a) -- This synonym isn't properly flattened The fix is easy, but sadly the bug is in the released GHC 7.8.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:18:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:18:54 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.1b47bb9111b1470057fe1456a3fd4815@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): Yes, I'm afraid that if I really have broken a number of significant packages since RC2, we probably should make a quick 7.8.2. Who else has come across this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:20:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:20:39 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.044ae1c154a078d51ae4c4c936df259a@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 snoyberg): Thanks Simon. I'll be happy to do any testing of such a release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:25:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:25:33 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.3a9aa9aee0fe4dff956ac3f052c7eb6b@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by maeder): see http://lists.gnu.org/archive/html/bug-autoconf/2014-04/msg00004.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:43:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:43:34 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.fd6927f853bb79f1ff9e7f3a916bad5e@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Compiler | Version: 7.8.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: ----------------------------------------------+---------------------------- Changes (by hvr): * priority: normal => highest * milestone: => 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:44:01 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:44:01 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.fe97c55343a1dc77213a55f4f749c134@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by kgardas): Fantastic work! Thanks a lot Christian. Are you going to create a patch following the advice? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:51:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:51:37 -0000 Subject: [GHC] #8977: GHC infinite loop on Solaris In-Reply-To: <046.13b621cf13f34e2cdfa5dc435aa4e508@haskell.org> References: <046.13b621cf13f34e2cdfa5dc435aa4e508@haskell.org> Message-ID: <061.13d02c0947502ab961e0cc47f81c79c5@haskell.org> #8977: GHC infinite loop on Solaris ---------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by trommler): * status: closed => new * resolution: wontfix => Comment: This looks like a duplicate of #7695. I am reopening and closing as duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:53:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:53:27 -0000 Subject: [GHC] #8977: GHC infinite loop on Solaris In-Reply-To: <046.13b621cf13f34e2cdfa5dc435aa4e508@haskell.org> References: <046.13b621cf13f34e2cdfa5dc435aa4e508@haskell.org> Message-ID: <061.11537107c959375e3a7ff6845565d89b@haskell.org> #8977: GHC infinite loop on Solaris -------------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7695 -------------------------------------+------------------------------------ Changes (by trommler): * status: new => closed * resolution: => duplicate * os: Solaris => Unknown/Multiple * related: => #7695 * milestone: => 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:54:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:54:12 -0000 Subject: [GHC] #8982: Your Overall Health Insurance Policies Message-ID: <045.0979f4f91591c2d8da36e97febeef8f8@haskell.org> #8982: Your Overall Health Insurance Policies ------------------------------------+------------------------------------- Reporter: scydv1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Purchase scrutiny contract can ply for anyone in every age groups. Disregarding if you are junior or old, the advantages of satisfactory reportage extend to everyone in every parts of order.It can be a nasty job to illustration out the reverse health protection contract for you. The mass will sure work you in having the first scrutiny eudaimonia insurance your money can buy. [http://try100puregarciniacambogia.com/ 100 Pure Garcinia Cambogia] If you prefer scrutiny contract, you should truly pair what your reportage present comprehend. Upbeat sum that addresses these strength variety any number having the potentiality to afford downtime you bump to be splashy for measure off should it turn required. When unresolved body comes around, inspect your eudaimonia upkeep protection plans and desires. Ingenuous body can be a corking dimension to improve modality and dental protection arrangement if it exists. When it is term for you to regenerate your contract, valuate your requirements when it comes to wellbeing protection. Unprotected entrance can even be the unexceeded dimension to transfer exteroception and dental protection drawing if it is forthcoming. Health aid shelter is extraordinary for outlay lower on your own taxes. The money spent on deductibles, visits or prescriptions that aren't smothered by shelter are also deductible. Neaten trustworthy you watch up on the guidelines for country and federal tax differences. Irrespective of how large your prosperity contract mean is, you'll prevent a lot of cash by opting for generic drugs over their sort obloquy equivalent. There are a few instances that you won't can get generics, and many research has shown there is sure not upright a mensurable preeminence between logo and generic, reserve the nominate. See your nation of eudaimonia contract coverage to conceptualise out which prescriptions characterize for amount. This name of drenched prescriptions changes annually, so translate it over any experience you regenerate your policy to see what is and isn't wrapped. If you wait to get enceinte soon, it is vital that you incur an contract policies that covers your expenses, from antenatal appointments to charges for have and deed. This is really influential vision as there are plans should not be profitable for destined pregnancy and experience. '''100 Pure Garcinia Cambogia''' Be sensitive of apiece melody of your calculate. Despite having an contract mean, the bills that travel up can draw you off hold, for monition prescription drugs. Several doctors exclusive dictate brand-name drug without greeting for your expenditure since they harbor't wise the generic is disposable. The expenditure of medicament could dissent between polar pharmacies. When shift shelter policies, get your uncastrated facts from your latest contract. Screw how such you pay annually, the allowable on your own policy and the kinds of expenses that leave be sealed after the allowable is remunerative. Save this with a flowing repeat of the paperwork handy to ply you really choose the superior insurance contract for you. http://try100puregarciniacambogia.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 07:56:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 07:56:53 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.b3f67ce47ecc6fe72216f00fde736b7b@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------ Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8977 -------------------------------------+------------------------------------ Changes (by trommler): * version: 7.6.2 => 7.8.1 * os: Linux => Unknown/Multiple * related: => #8977 * milestone: 7.8.1 => 7.8.2 Comment: This was also reported on Solaris. See #8977. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 08:09:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 08:09:25 -0000 Subject: [GHC] #7068: Extensive Memory usage (regression) In-Reply-To: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> References: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> Message-ID: <063.3549845e873047a5a98d03e132d0713d@haskell.org> #7068: Extensive Memory usage (regression) -------------------------------------------------+------------------------- Reporter: waldheinz | Owner: Type: bug | simonpj Priority: high | Status: new Component: Compiler | Milestone: 7.8.1 Resolution: | Version: 7.4.1 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 gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 09:03:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 09:03:51 -0000 Subject: [GHC] #8153: Implement AES intrinsics In-Reply-To: <046.7805615205ec3ee99fe013f4dbb71d81@haskell.org> References: <046.7805615205ec3ee99fe013f4dbb71d81@haskell.org> Message-ID: <061.43b16d54144ddd309e011cb76bf29d22@haskell.org> #8153: Implement AES intrinsics ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 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 rrnewton): What other option is there than providing a fallback? Simply making it a compiler error to build for any arch that doesn't have AESNI? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 09:09:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 09:09:53 -0000 Subject: [GHC] #8157: Add a broader set of (C/CMM-based) atomic memory operations In-Reply-To: <047.a2c19331f284f809c28a9f4841899a32@haskell.org> References: <047.a2c19331f284f809c28a9f4841899a32@haskell.org> Message-ID: <062.3c4de7e0ece24872878dcb3f0d2adc22@haskell.org> #8157: Add a broader set of (C/CMM-based) atomic memory operations -------------------------------------+------------------------------------ Reporter: rrnewton | Owner: rrnewton 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 rrnewton): * status: new => closed * resolution: => fixed Comment: The basic functionality described above has now been implemented in GHC 7.8. This ticket is closed, but please refer to #7883, which discusses the next round of improvements for atomic ops. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 09:11:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 09:11:27 -0000 Subject: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? In-Reply-To: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> References: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> Message-ID: <060.b77dfe13732d12644d1a4cb0619aa785@haskell.org> #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): FYI, Johan (@tibbe) is interested in this. Carter, have you started the implementation somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 09:20:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 09:20:51 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.4e17d478bc987c521d16a4beaefba3f1@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Comment (by maeder): I still propose https://ghc.haskell.org/trac/ghc/attachment/ticket/8783/0001-do-not- confuse-configure-by-a-bash-shell.patch to be applied as is. (This would make my building easier for me.) I don't mind to change libffi/ghc.mk, too, as Edward (ezyang) suggested, but this is not crucial (for my builds). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 09:34:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 09:34:17 -0000 Subject: [GHC] #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc-citeproc In-Reply-To: <045.b3bb12ede69a22b49498521b36f8f9a8@haskell.org> References: <045.b3bb12ede69a22b49498521b36f8f9a8@haskell.org> Message-ID: <060.ada3784aaab6287b612597dcf97d0186@haskell.org> #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc- citeproc -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): So this is another example of the `SpecConstr` blow-up, cf #7898, #7068, #7944, #5550, #8836. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 09:34:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 09:34:28 -0000 Subject: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? In-Reply-To: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> References: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> Message-ID: <060.3454824058b682c8a89b8f58f33fb69d@haskell.org> #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * cc: johan.tibell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 10:59:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 10:59:16 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.dc7eff6bb045c0f35a8375fb7379eade@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): I've decided to investigate things further. After firing GDB I've seen a painfully familiar picture of what I saw at #8834. Looking into LLVM codegen code i see [http://git.haskell.org/ghc.git/blob/HEAD:/compiler/llvmGen/LlvmCodeGen/CodeGen.hs#l1566 ... For Caller save registers across C calls the saving and restoring of them is done by the Cmm code generator, using Cmm local vars. So to stop LLVM saving them as well (and saving all of them since it thinks they're always live, we trash them just before the call by assigning the 'undef' value to them. The ones we need are restored from the Cmm local var and the ones we don't need are fine to be trashed.] But recent #8834 saga teach us that after [http://git.haskell.org/ghc.git/blobdiff/66aa489fcbfca30dc3c3b553fce4f1e4debfb7c1..ad15c2b4bd37082ce989268b3d2f86a2cd34386a:/compiler/cmm/CmmSink.hs] this already is not the case. And after this [http://git.haskell.org/ghc.git/commitdiff/c4eeacdfdf4578eb6e75bbf2e067bfe70ec94ab0 NCG became responsible for saving registers across the C call]. It looks LLVM backend still does not take this into account. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 11:03:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 11:03:14 -0000 Subject: [GHC] #8982: Heap profile restricted by biography of GHC segfaults Message-ID: <045.2f1c274c99888d78a46f11c380acbc26@haskell.org> #8982: Heap profile restricted by biography of GHC segfaults ----------------------------------+---------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Steps to reproduce: 1. Build GHC with profiling on 64-bit Linux 2. Run T1969 with RTS options -hc -hbvoid {{{ [ezyang at hs01 compiler]$ '/home/hs01/ezyang/ghc-compalloc/inplace/bin/ghc- stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T1969.hs +RTS -V0 -tT1969.comp.stats --machine- readable -RTS -dcore-lint -static +RTS -hc -hbvoid Segmentation fault }}} Interestingly enough, I don't see the problem with other types of profiling, e.g. '-hd'. I tried a few simpler, nontrivial Haskell programs but I couldn't reproduce the segfault, so this is some sort of bug that only shows up in complex setting (maybe multithreading is the issue?) It reproduces quite reliably for me. When I build the runtime system with debugging, I get a useful assert failure: {{{ ghc-stage2: internal error: ASSERTION FAILED: file rts/ProfHeap.c, line 201 (GHC version 7.8.0.20140408 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This assert is complaining that the cost center (CCS_SYSTEM) never made it into the hash table for era 149. I'll try looking for a simpler test-case later, but maybe someone can figure out what this bug is by sight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 11:04:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 11:04:17 -0000 Subject: [GHC] #8982: Cost center heap profile restricted by biography of GHC segfaults (was: Heap profile restricted by biography of GHC segfaults) In-Reply-To: <045.2f1c274c99888d78a46f11c380acbc26@haskell.org> References: <045.2f1c274c99888d78a46f11c380acbc26@haskell.org> Message-ID: <060.11fb815da029dcc41e0d2cff19dd30e3@haskell.org> #8982: Cost center heap profile restricted by biography of GHC segfaults ----------------------------------+---------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 11:38:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 11:38:12 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.f0d21256073f817c9a7dc2338362c25a@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): As it turns out, removing HEAP_ALLOCED has a bad interaction with object unloading. The immediate failure is that the unload-object code thinks that all objects are unreferenced when checking static closures, because the static closure doesn't live in the object image but in the dynamic heap. One way to fix this is to add some extra data to all static closures saying where their indirection lives and use that to determine if a static closure is associated an unloaded object. Then when we dynamically load an object, we place all of its static closures in a block allocated specifically for that object (this would only work for GHC's linker, but as it so happens, at the moment we only support unloading static objects and not dynamic libraries); once we conclude the object is dead we free the block back to the memory manager. Here's an alternative scheme. Since the static closures no longer live in the object image, we can treat them as normal closures and just check if their info tables are keeping an object live. However, we still need to make sure that space in the static blocks ends up getting freed; the most reliable way to do that is to actually GC static closures the same we GC normal objects. (But of course, if we do that, we still need pointers to the static indirections to update them when the static object moves somewhere else.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 11:38:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 11:38:35 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.21f4df0e98d19dccc95d3aa5e22b54b9@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): I've tried to make LLVM codegen to not trash anything (`getTrashRegs = return []`) but the problem is still here. Hence either my analysis is wrong or incomplete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 12:01:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 12:01:37 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.c2daf904a0ed448aa65328b6ff15a86f@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): I've been keeping an eye on the performance numbers, and this patch to the compiler results in a modest bump in some of the stats that we are testing on: {{{ =====> T3294(normal) 1380 of 3913 [0, 3, 0] cd ./perf/compiler && '/home/hs01/ezyang/ghc-heap-alloced/inplace/bin/ghc- stage2' -fforce-recom p -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3294.hs +RTS -V0 -tT32 94.comp.stats --machine-readable -RTS >T3294.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 43224080 +/-15% Lower bound max_bytes_used: 36740468 Upper bound max_bytes_used: 49707692 Actual max_bytes_used: 54141136 *** unexpected failure for T3294(normal) =====> T4801(normal) 1381 of 3913 [0, 4, 0] cd ./perf/compiler && '/home/hs01/ezyang/ghc-heap-alloced/inplace/bin/ghc- stage2' -fforce-recom p -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T4801.hs +RTS -V0 -tT48 01.comp.stats --machine-readable -RTS -static >T4801.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 392409984 +/-10% Lower bound bytes allocated: 353168985 Upper bound bytes allocated: 431650983 Actual bytes allocated: 446748968 *** unexpected failure for T4801(normal) =====> T3064(normal) 1382 of 3913 [0, 5, 0] cd ./perf/compiler && '/home/hs01/ezyang/ghc-heap-alloced/inplace/bin/ghc- stage2' -fforce-recom p -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT30 64.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 329795912 +/-5% Lower bound bytes allocated: 313306116 Upper bound bytes allocated: 346285708 Actual bytes allocated: 350480296 *** unexpected failure for T3064(normal) =====> T5837(normal) 1391 of 3913 [0, 6, 0] cd ./perf/compiler && '/home/hs01/ezyang/ghc-heap-alloced/inplace/bin/ghc- stage2' -fforce-recom p -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5837.hs -ftype-function -depth=50 +RTS -V0 -tT5837.comp.stats --machine-readable -RTS >T5837.comp.stderr 2>&1 =====> T6048(optasm) 1392 of 3913 [0, 6, 0] cd ./perf/compiler && '/home/hs01/ezyang/ghc-heap-alloced/inplace/bin/ghc- stage2' -fforce-recom p -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS - V0 -tT6048.comp.stats --machine-readable -RTS >T6048.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 108578664 +/-10% Lower bound bytes allocated: 97720797 Upper bound bytes allocated: 119436531 Actual bytes allocated: 121958160 }}} The bump is understandable, because I need to do some post-processing on the C-- stream which induces some extra allocation. I think I might be able to optimize it some more but it would be nice to know if it's OK to bump these figures up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 12:02:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 12:02:32 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.9d74ececa483e4f2b8d65ef6c5139b90@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Description changed by ezyang: Old description: > This bug is to track progress of removing HEAP_ALLOCED from GHC, > promising faster GC (especially for large/scattered heaps), as long as we > can keep the cost of indirections down. > > The relevant wiki article: > http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; > we are implementing method 2. Version 2 of the patchset is probably > correct. > > Blocking problems: > > * Properly handle the Windows DLL case (e.g. SRTs). We will probably have > to reorganize how the indirections are laid out. > > * ~~Make it work for GHCi linking of static objects.~~ Blocked on #2841, > I have it working for ELF, and can make it work for other platforms as > soon as I get relevant machines. > > * Bikeshed hs_main API changes (because closures are not valid prior to > RTS initialization, so you have to pass in an indirection instead) > > Performance improvements possible: > > * ~~This patch introduces a lot of new symbols; ensure we are not unduly > polluting the symbol tables. (In particular, I think _static_closure > symbols can be made hidden).~~ I've eliminated all of these except for > the init symbols, which cross the stub object and assembly file boundary, > and so would need to be made invisible by the linker. > > * Don't pay for a double indirection when -fPIC is turned on. Probably > the easiest way to do this is to *not* bake in the indirections into > compiled code when it is -fPIC'd, and instead scribble over the GOT. > However, I don't know how to go backwards from a symbol to a GOT entry, > so we might need some heinous assembly hacks to get this working. > > * The old HEAP_ALLOCED is supposed to be pessimal on very large heaps. Do > some performance tests under those workloads. > > * Make sure the extra indirection is not causing any C-- optimizations to > stop firing (it might be, because I put it in as a literal CmmLoad) > > * Once an static thunk is updated, we can tag the indirection to let > other code segments to know about the good news. One way to do this is > have the update frame for a static indirection should have a reference to > the *indirection*, not the closure itself. However, this scheme will not > affect other static closures which have references to the thunk. > > * Closure tables should have their indirections short-circuited by the > initialization code. But maybe it is not worth the cost of telling the > RTS about the closure tables (also, they would need to be made > writeable). > > * We are paying an indirection when a GC occurs when the closure is not > in R1. According to the wiki page, technically this is not needed, but I > don't know how to eliminate references to the closure itself from > stg_gc_fun. > > * ~~Save tags inside the indirection tables, so that we don't spend > instructions retagging after the following the indirection.~~ Done. > > * ~~Improve static indirection and stable pointer registration, avoiding > binary bloat from `__attribute(constructor)__` stubs.~~ After discussing > this with some folks, it seems that there isn't really a portable way to > do this when we are using the system dynamic linker to load libraries at > startup. The problem is that we need to somehow get a list of all the > GHC-compiled libraries which got loaded, and really the easiest way to > get that is to just build it ourselves. > > * ~~Need to implement a new megablock tracking structure so we can > free/check for lost blocks~~. Now that efficient lookup is not necessary, > perhaps we can write-optimize the megablock tracking structures. > > Speculative improvements: > > * Now that static lives in a block, can we GC them like we GC normal > data? This would be beneficial for static thunks, which now can have > their indirections completely removed; reverting CAFs may be somewhat > tricky, however. > > * Now that HEAP_ALLOCED is greatly simplified, can we further simply some > aspects of the GC? At the very least, we ought to be able to make > megablock allocation cheaper, by figuring out how to remove the > spinlocks, etc. > > * Another possibility is to adopt a hybrid approach, where we manually > lay out closures when compiling statically, and indirect when compiling > dynamically. In some sense, this gets the best of both worlds, since we > expect to not pay any extra cost for indirection due to PIC. New description: This bug is to track progress of removing HEAP_ALLOCED from GHC, promising faster GC (especially for large/scattered heaps), as long as we can keep the cost of indirections down. The relevant wiki article: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; we are implementing method 2. Version 2 of the patchset is probably correct. Blocking problems: * Properly handle the Windows DLL case (e.g. SRTs). We will probably have to reorganize how the indirections are laid out. * ~~Make it work for GHCi linking of static objects.~~ Blocked on #2841, I have it working for ELF, and can make it work for other platforms as soon as I get relevant machines. * Bikeshed hs_main API changes (because closures are not valid prior to RTS initialization, so you have to pass in an indirection instead) * Does not work with unloadObj (see comments below) Performance improvements possible: * ~~This patch introduces a lot of new symbols; ensure we are not unduly polluting the symbol tables. (In particular, I think _static_closure symbols can be made hidden).~~ I've eliminated all of these except for the init symbols, which cross the stub object and assembly file boundary, and so would need to be made invisible by the linker. * Don't pay for a double indirection when -fPIC is turned on. Probably the easiest way to do this is to *not* bake in the indirections into compiled code when it is -fPIC'd, and instead scribble over the GOT. However, I don't know how to go backwards from a symbol to a GOT entry, so we might need some heinous assembly hacks to get this working. * The old HEAP_ALLOCED is supposed to be pessimal on very large heaps. Do some performance tests under those workloads. * Make sure the extra indirection is not causing any C-- optimizations to stop firing (it might be, because I put it in as a literal CmmLoad) * Once an static thunk is updated, we can tag the indirection to let other code segments to know about the good news. One way to do this is have the update frame for a static indirection should have a reference to the *indirection*, not the closure itself. However, this scheme will not affect other static closures which have references to the thunk. * Closure tables should have their indirections short-circuited by the initialization code. But maybe it is not worth the cost of telling the RTS about the closure tables (also, they would need to be made writeable). * We are paying an indirection when a GC occurs when the closure is not in R1. According to the wiki page, technically this is not needed, but I don't know how to eliminate references to the closure itself from stg_gc_fun. * ~~Save tags inside the indirection tables, so that we don't spend instructions retagging after the following the indirection.~~ Done. * ~~Improve static indirection and stable pointer registration, avoiding binary bloat from `__attribute(constructor)__` stubs.~~ After discussing this with some folks, it seems that there isn't really a portable way to do this when we are using the system dynamic linker to load libraries at startup. The problem is that we need to somehow get a list of all the GHC-compiled libraries which got loaded, and really the easiest way to get that is to just build it ourselves. * ~~Need to implement a new megablock tracking structure so we can free/check for lost blocks~~. Now that efficient lookup is not necessary, perhaps we can write-optimize the megablock tracking structures. Speculative improvements: * Now that static lives in a block, can we GC them like we GC normal data? This would be beneficial for static thunks, which now can have their indirections completely removed; reverting CAFs may be somewhat tricky, however. * Now that HEAP_ALLOCED is greatly simplified, can we further simply some aspects of the GC? At the very least, we ought to be able to make megablock allocation cheaper, by figuring out how to remove the spinlocks, etc. * Another possibility is to adopt a hybrid approach, where we manually lay out closures when compiling statically, and indirect when compiling dynamically. In some sense, this gets the best of both worlds, since we expect to not pay any extra cost for indirection due to PIC. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 12:11:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 12:11:46 -0000 Subject: [GHC] #8153: Implement AES intrinsics In-Reply-To: <046.7805615205ec3ee99fe013f4dbb71d81@haskell.org> References: <046.7805615205ec3ee99fe013f4dbb71d81@haskell.org> Message-ID: <061.2b631f9a1ae6cc9dacaad751c125aa2b@haskell.org> #8153: Implement AES intrinsics ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: closed request | Milestone: Priority: low | Version: Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => wontfix Comment: I personally think this ticket is misguided and an extremely bad idea. There's almost no reason for GHC to provide cryptographic primitives like this. First off, they're ridiculously unportable, powered only on AArch64 (which we don't support at all) and AES-NI enabled Intel machines. Anything else either A) doesn't get support and the compiler bails or B) we have to implement a fallback. For A), that's terrible, because it basically means the intrinsics are unusable for large classes of people. What's the point if most people can't use it? And B) is terrible too, because implementing a correct, constant-time version of AES is tricky and we'd have to rip someone's code in practice and then call out to it, yadda yadda. But the tricker part about B is that the AES-NI intrinsics do *not* just let you do AES! They are specifically designed to allow you to design your own key schedules or other algorithms based on AES. It is *specifically* designed to be this flexible! A software implementation would have to match these characteristics, it's not as simple as "EncryptAESBytes()" and "DecryptAESBytes()" in C code and calling out to that. The design would need to be more involved. But fundamentally - *why* should this be in GHC? It just seems like adding intrinsics for the sake of it because it sounds cool. Compilers like GHC are simply no place for this. I don't buy the argument we can inline mildly better, and I don't think GHC is going to do a better job of utilizing these primitives than an external library can. AES-NI in particular is sensitive to the performance and schedule of surrounding code in my experience - a small wibble can easily increase/decrease speeds from 20% or more, and at the levels we're talking about, that's an absolutely ludicrous difference - and I can guarantee GHC is almost certainly not going to come up with a better schedule than GCC on my hand- optimized AES-NI example. And again - AES-NI is often used in custom ways. Once you begin doing this and bouncing between the primops (like keygenassist and rounds of aesenc) in-a-not-strictly-AES-fashion, I'm almost certain GHC is not going to compete with GCC, which will be able to produce a much better schedule and code And finally, as a security engineer in a prior life: putting cryptography here is just a terrible idea from a security perspective. This is all just better left to a library which is isolated, small, auditable, and most importantly '''not tied to GHC in any way'''. This is crucial. I would personally be skeptical of such an approach as it ties so much complexity into GHC vs just using some C code. The C code is easier to audit, verify, and examine. I see no point in adding this and I personally think it's just meaningless bloat, and I'm strongly inclined to not accept patches for this even if someone were to write them. So I'm going to close this ticket. But if you can convince me otherwise, let's hear it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 12:25:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 12:25:55 -0000 Subject: [GHC] #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory (was: ghc with -odir and -prof does not create the specified output directory) In-Reply-To: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> References: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> Message-ID: <063.08988f047dfa1e3abaaa4ed961ae4d1b@haskell.org> #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory ---------------------------------------+----------------------------------- Reporter: wmarshall | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 ezyang): * owner: => ezyang * version: 7.6.3 => 7.9 Comment: Applies to Linux too. The actual source of the problem is when compilation of the file involves a stub file (so foreign exports will trigger this too); we've forgotten to call createDirectoryIfMissing in DriverPipeline.hs. Should be easy to fix but I need to cook up a test- case... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 12:41:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 12:41:48 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.669d4145448c18855b1373067ae8bda5@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged in 7.8, thanks Simon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 12:43:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 12:43:56 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.b7b10ec045134680f6cd85bdb643506b@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: Resolution: fixed | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple simplCore/should_compile/T8848, T8848a | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: closed => merge * milestone: 7.8.2 => 7.8.3 Comment: This shouldn't be marked fixed. 7.8.2 will be a critical bugfix release, but I think we'll punt this for consideration to 7.8.3 instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 12:46:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 12:46:14 -0000 Subject: [GHC] Batch modify: #8977, #8848, #8954, #5987, #7602, #8228, #8376, #8736, #8746, #8935, #8974, #7655, #7695, #8620, #8728, #8731, #8761, #8866, #8976, #8981, #8683 Message-ID: <20140410124614.606FE24069@ghc.haskell.org> Batch modification to #8977, #8848, #8954, #5987, #7602, #8228, #8376, #8736, #8746, #8935, #8974, #7655, #7695, #8620, #8728, #8731, #8761, #8866, #8976, #8981, #8683 by thoughtpolice: milestone to 7.8.3 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 12:58:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 12:58:59 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.9c0c7d40df3c3c26898aea1977ef3c86@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): So we have to solve the unloading problem first, right? Also did you find any way to reduce that 5-6% binary size overhead? Before bumping the performance thresholds you should check whether they're reasonable. Compare against the unpatched compiler (sometimes it is right up against the upper limit anyway). Increasing allocation by 10% sounds like a *lot* for this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 13:01:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 13:01:04 -0000 Subject: [GHC] #8816: Make SPARC registerised again. In-Reply-To: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> References: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> Message-ID: <061.d1b8b7396e7bbc9968df5419ed8cbe0a@haskell.org> #8816: Make SPARC registerised again. ------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8847 Blocking: | Related Tickets: ------------------------------------+--------------------------- Changes (by kgardas): * version: 7.6.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 13:08:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 13:08:30 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.a7b26d3e49428cc435aadc80e978ef71@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8157, 7883 -------------------------------------+------------------------------------ Comment (by rrnewton): Update: I confirmed that I get the exact same time for "Data.Atomics.Counter' (atomic-primops) as I do for Johan (tibbe)'s counter.c version of the benchmark here. Johan and I talked about this and it seems like the obvious way to improve performance on this is inline primops for the fetch-and-add (#7883). We confirmed that the MutableByteArray# used by Data.Atomics.Counter is a single contiguous heap object, so the only advantage of a dedicated mutable reference type would be to save the word representing the length. More, generally, I wonder if we can have a user facing interface that makes mutable unboxed data more pleasant. Unboxed vectors are nice, but there's nothing like an (IORef (# Int#, Int# #)), for example. Even though with double-word CAS we could support some interesting data types... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 16:28:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 16:28:09 -0000 Subject: [GHC] #8981: ghc-pkg complains about missing haddock interface files In-Reply-To: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> References: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> Message-ID: <067.4b6fe7de2de0ae1a7911e9f46bcc61f9@haskell.org> #8981: ghc-pkg complains about missing haddock interface files ------------------------------------------------+-------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1 Resolution: | Keywords: ghc- Operating System: MacOS X | pkg Type of failure: Incorrect result at runtime | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by conal): * cc: conal@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 16:41:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 16:41:44 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.85d88c7e85b35f738249676e127e5c41@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there ----------------------------+---------------------------------------------- Reporter: hpd | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less than a day) Type of failure: Runtime | Blocked By: crash | Related Tickets: #8977 Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by trommler): * owner: => trommler * difficulty: Unknown => Moderate (less than a day) * failure: None/Unknown => Runtime crash Comment: OK, I'll take a stab at that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 18:09:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 18:09:39 -0000 Subject: [GHC] #8918: Network package doesn't load under GHC 7.8 RC on windows (?) In-Reply-To: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> References: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> Message-ID: <062.f802978731de817b4264b138b93a3415@haskell.org> #8918: Network package doesn't load under GHC 7.8 RC on windows (?) --------------------------------------+---------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+---------------------------------- Comment (by schernichkin): Same problem in 7.8.1: {{{ Loading package network-2.4.2.2 ... linking ... ghc.exe: unable to load package `network-2.4.2.2' ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: D:\Haskell\lib\x86_64-windows- ghc-7.8.1\network-2.4.2.2\HSnetwork-2.4.2.2.o: unknown symbol `WspiapiGetNameInfo' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From kyrab at mail.ru Thu Apr 10 18:26:11 2014 From: kyrab at mail.ru (kyra) Date: Thu, 10 Apr 2014 22:26:11 +0400 Subject: [GHC] #8918: Network package doesn't load under GHC 7.8 RC on windows (?) In-Reply-To: <062.f802978731de817b4264b138b93a3415@haskell.org> References: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> <062.f802978731de817b4264b138b93a3415@haskell.org> Message-ID: <5346E243.1010707@mail.ru> Oh, I know what is going here. This is a problem in either mingw-w64 (which goes bundled with GHC) or with network package (or both). Ancient wsiapi functions (absent in all reasonable modern windozes) turned to be popped up. One of the possible workarounds is thus: replace your \mingw\x86_64-w64-mingw32\include\wspiapi.h file with an empty file and reconfigure and rebuild the network package. Cheers, Kyra On 4/10/2014 22:09, GHC wrote: > #8918: Network package doesn't load under GHC 7.8 RC on windows (?) > --------------------------------------+---------------------------------- > Reporter: dmcclean | Owner: > Type: bug | Status: new > Priority: normal | Milestone: > Component: libraries (other) | Version: 7.8.1-rc1 > Resolution: | Keywords: > Operating System: Windows | Architecture: x86_64 (amd64) > Type of failure: None/Unknown | Difficulty: Unknown > Test Case: | Blocked By: > Blocking: | Related Tickets: > --------------------------------------+---------------------------------- > > Comment (by schernichkin): > > Same problem in 7.8.1: > {{{ > Loading package network-2.4.2.2 ... linking ... ghc.exe: unable to load > package `network-2.4.2.2' > ghc.exe: warning: WSACleanup from ws2_32 is linked instead of > __imp_WSACleanup > ghc.exe: warning: WSAStartup from ws2_32 is linked instead of > __imp_WSAStartup > ghc.exe: warning: WSACleanup from ws2_32 is linked instead of > __imp_WSACleanup > ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept > ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of > __imp_inet_ntoa > ghc.exe: D:\Haskell\lib\x86_64-windows- > ghc-7.8.1\network-2.4.2.2\HSnetwork-2.4.2.2.o: unknown symbol > `WspiapiGetNameInfo' > }}} > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > _______________________________________________ > ghc-tickets mailing list > ghc-tickets at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-tickets > From ghc-devs at haskell.org Thu Apr 10 18:26:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 18:26:56 -0000 Subject: [GHC] #8918: Network package doesn't load under GHC 7.8 RC on windows (?) In-Reply-To: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> References: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> Message-ID: <062.5e69074c3a4b784b3d86e2d338c70fe1@haskell.org> #8918: Network package doesn't load under GHC 7.8 RC on windows (?) --------------------------------------+---------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+---------------------------------- Comment (by awson): This is a problem in either mingw-w64 (which goes bundled with GHC) or with network package (or both). Ancient wsiapi functions (absent in all reasonable modern windozes) turned to be popped up. One of the possible workarounds is thus: replace your \mingw\x86_64-w64-mingw32\include\wspiapi.h file with an empty file and reconfigure and rebuild the network package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 19:48:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 19:48:47 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.efa53abbfce23bed0c2fb85414cd4116@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Replying to [comment:6 kosmikus]: > Both `P` in SPJ's example and `C` in my examples are bidirectional pattern synonyms, and as an expression, it should be easy enough for GHC to type-check without a type signature. So why require one in this case? The expression type signature and pattern type signature must be the same, after all. No, that statement sounds plausible, but it is not right. Consider {{{ data T a where T1 :: a -> T a T2 :: T Int T3 :: T Bool }}} In an expression context, certainly, `T2 :: T Int`, and `T3 :: T Bool`. But '''not''' in a pattern context, otherwise this function would be ill- typed: {{{ f (T1 _) = True f T2 = True f T3 = False }}} No, as a pattern, both `T2` and `T3` have type `forall a. T a`; that is, they can soundly (without seg-faulting) match any value of type `T `. So `f :: T a -> Bool`. But try this: {{{ g (T1 True) = True g T2 = True g T3 = False }}} Here the first equation means that applying `g` to an argument of type `T Int`, say, would be unsound. The pattern `T1 True :: T Bool`, and indeed `g :: T Bool -> Bool`, and the `T2` clause is dead code. The trouble is that (as we know well) in the presence of GADTs there may be no unique principal type, which is why !OutsideIn requires type signatures to resolve the uncertainty. It's the same with pattern synonyms. However, a key principle is that replacing pattern synonym by its definition should not change whether the program is well typed. So is is a bug that these two behave differently: {{{ f :: X Maybe a -> a f (Y (Just x)) = x -- works f (C x) = x -- fails }}} The latter should not fail; it should behave precisely like the former. The "not in scope during type checking" error is a bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 20:05:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 20:05:43 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM3ODcwOiBDb21waWxhdGlv4oCLbiBlcnJvcnMg?= =?utf-8?q?break_the_complexity_encapsulat=E2=80=8Bion_on_DSLs=2C?= =?utf-8?q?_impairs_success_in_industry?= In-Reply-To: <048.de52b4bfe321c3b82b9c52c180790492@haskell.org> References: <048.de52b4bfe321c3b82b9c52c180790492@haskell.org> Message-ID: <063.50ddb3f66a55d7902fced23223fe26cd@haskell.org> #7870: Compilatio?n errors break the complexity encapsulat?ion on DSLs, impairs success in industry --------------------------------------------+------------------------------ Reporter: agocorona | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: DSL, Operating System: Unknown/Multiple | Error, Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by Lemming): * cc: ghc@? (added) * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 20:11:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 20:11:55 -0000 Subject: [GHC] #8153: Implement AES intrinsics In-Reply-To: <046.7805615205ec3ee99fe013f4dbb71d81@haskell.org> References: <046.7805615205ec3ee99fe013f4dbb71d81@haskell.org> Message-ID: <061.f79e5a6d4d349db923483f6380ad3f7e@haskell.org> #8153: Implement AES intrinsics ----------------------------+---------------------------------------------- Reporter: schyler | Owner: Type: feature | Status: closed request | Milestone: Priority: low | Version: Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by rrnewton): I tend to agree with the previous comment. I built one crypto PRNG lib using AESNI (in foreign code). It just seems like there aren't that many uses of it, and that it's fine to keep it in foreign code. That's in stark contrast with the SIMD primops, where you really want it to be inline inside your numeric loops (and its a wide variety of loops/algorithms that can use it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 20:20:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 20:20:49 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.bee619511a5e1aadef7b59e952979ef7@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): Replying to [comment:7 simonpj]: > Replying to [comment:6 kosmikus]: > > Both `P` in SPJ's example and `C` in my examples are bidirectional pattern synonyms, and as an expression, it should be easy enough for GHC to type-check without a type signature. So why require one in this case? The expression type signature and pattern type signature must be the same, after all. > > No, that statement sounds plausible, but it is not right. Consider > {{{ > data T a where > T1 :: a -> T a > T2 :: T Int > T3 :: T Bool > }}} > In an expression context, certainly, `T2 :: T Int`, and `T3 :: T Bool`. But '''not''' in a pattern context, otherwise this function would be ill- typed: > {{{ > f (T1 _) = True > f T2 = True > f T3 = False > }}} > No, as a pattern, both `T2` and `T3` have type `forall a. T a`; that is, they can soundly (without seg-faulting) match any value of type `T `. So `f :: T a -> Bool`. Ok, we seem to have slightly different terminology when it comes to saying what the "type" of a pattern is. But terminology aside, I agree that `T2` and `T3` should be applicable in a context of type `T a`. But the information that they're `T Int` and `T Bool` "as an expression" must still be around even during pattern matching, because the match causes type refinement accordingly. So in one way or another for a constructor such as `T2` there seem to be *two* types that are important, namely `T Int` and `forall a. T a`. > The trouble is that (as we know well) in the presence of GADTs there may be no unique principal type, which is why !OutsideIn requires type signatures to resolve the uncertainty. It's the same with pattern synonyms. This is what I also thought at first, but what I'm no longer convinced about. Let's go back to your example: {{{ data T a b where MkT :: a -> T a Bool MkX :: T a b pattern P = MkT True }}} So I guess we agree than "as an expression", `P` must be of type `T Bool Bool`. You say that "as a pattern", it could have either of {{{ P :: T Bool b P :: T b b }}} Yes, ok, but should this information be necessary to provide with the pattern synonym? Isn't this something that should be derived from the type signature of the function in which it is used? Shouldn't I be able to write {{{ f :: T Bool b -> b f P = False }}} and also {{{ g :: T b b -> b g P = False }}} just like I can write {{{ f :: T Bool b -> b f (MkT True) = False }}} as well as {{{ g :: T b b -> b g (MkT True) = False }}} If I'd be forced to provide a type signature for the pattern synonym `P` picking one of the two "pattern types", then `P` would be necessarily more limited in its use than its expansion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 20:21:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 20:21:48 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.5e62ce1c689ed67faea2df94a85f3e7b@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): The above discussion sheds light on the "not in scope" error. Of course, it's a GHC panic, so it's not right. But that's because there really is a problem. * As a pattern `Y (Just x) :: X Maybe a` * As a expression `Y (Just x) :: X Maybe Int`, and requires `x::Int`. So it's not clear that a single signature for the two ways of looking at the RHS makes sense at all! It look as though we need one for its use as a pattern and one for its use as an expression. Sigh. Mind you, the "type as an expression" is easily inferred, as you mention. So perhaps the pattern signature (once we have them) can be taken as applying only to the pattern, not the expression? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 20:32:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 20:32:55 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.492a24a870dc07bd7653e2eb3f953425@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): > So it's not clear that a single signature for the two ways of looking at the RHS makes sense at all! It look as though we need one for its use as a pattern and one for its use as an expression. Sigh. Yes. > Mind you, the "type as an expression" is easily inferred, as you mention. So perhaps the pattern signature (once we have them) can be taken as applying only to the pattern, not the expression? I guess it's not clear to me if the other information isn't available as well, if the synonym is used in a function that has a type signature. Is there really a theoretical need to supply a signature for the "pattern type"? See my example in the other comment, I actually wouldn't like to have to pick one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 20:34:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 20:34:14 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.4b4260779926deda0e9e2deef94e6f14@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Replying to [comment:8 kosmikus]: > Yes, ok, but should this information be necessary to provide with the pattern synonym? Isn't this something that should be derived from the type signature of the function in which it is used? Yes, it should be provided with the pattern synonym. No, it should not be derived form the use. Here's why. As you go on to show, the "derive from use" idea is more flexible, '''but it is fundamentally non-modular''': you can only understand when a pattern synonym will typecheck by expanding it! The whole point about pattern synonyms is that you ''don't'' need to think about their implementation (expansion); you can reason about them using only their interface. To take an analogy, go back to GADTs: {{{ data T a where T1 :: T Bool T2 :: T Char f T1 = True }}} Does `f :: T a -> Bool` or `f :: T a -> a`? You could say "look to the uses". Here are two calls {{{ (f 'x' && True) -- Needs f :: T a -> Bool (ord (f 'x')) -- Needs f :: T a -> a }}} If you inline `f` (akin to expanding the pattern synonym), you can make both typecheck. But we don't inline functions: we give them a single, principal type, and use that at every call site. It's just the same with pattern synonyms. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 20:43:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 20:43:05 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.0492192be8ceffa29c615d6400c97b4e@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): I agree completely with the function example. I'm just sure about whether the pattern synonym situation is really analogous. The reason is that in {{{ data T a b where MkT :: a -> T a Bool MkX :: T a b pattern P = MkT True }}} I could just pretend that `P` is another constructor of `T`: {{{ data T a b where MkT :: a -> T a Bool MkX :: T a b P :: T Bool Bool }}} Then both `f` and `g` as shown above using `P` would type-check. So if for `P` as a constructor, the information that the "expression type" is `T Bool Bool` and the "target type" is `T a b` is sufficient, then why can't we do the same for `P` as a pattern synonym. That's still modular, IMHO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 21:08:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 21:08:37 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.6ba748b7f3607b4c5e71f637393eb1a7@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): > I could just pretend that `P` is another constructor of `T`: > {{{ > data T a b where > MkT :: a -> T a Bool > MkX :: T a b > P :: T Bool Bool > }}} Alas, no. If the definition of T really did have that constructor P, then GADT-style type refinement would take place when you match on P. So for example, this would typecheck: {{{ f :: T a b -> a -> Bool f P v = v && True }}} But obviously the expansion does not: {{{ f :: T a b -> a -> Bool f (MkT x) v = v && True }}} Moreover, these are terribly simple examples. In general a pattern synonym might mention dozens of constructor from dozens of types. Which of those types would you like to pretend the pattern synonym constructor is from? This is what I mean by modularity: no matter how complicated the right hand side of the pattern synonym, I want the client (of the library defining the pattern synonym) to be able to use it by knowing only its type -- just like he can for a function exported by a library. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 21:50:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 21:50:44 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.e4fc8f905a3f60de1180cb847488fa35@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): > Alas, no. If the definition of T really did have that constructor P, then GADT-style type refinement would take place when you match on P. So for example, this would typecheck: > {{{ > f :: T a b -> a -> Bool > f P v = v && True > }}} > But obviously the expansion does not: > {{{ > f :: T a b -> a -> Bool > f (MkT x) v = v && True > }}} The expansion is `MkT True`, but it doesn't matter. Nice example. I'm almost convinced, although I'll have to think about this a bit longer. > Moreover, these are terribly simple examples. In general a pattern synonym might mention dozens of constructor from dozens of types. Which of those types would you like to pretend the pattern synonym constructor is from? I don't pretend that I have thought this through. I have only played with pattern synonyms for a few days so far, and I don't completely understand the possibilities of the interaction with ViewPatterns yet. However, in the case of bidirectional pattern synonyms I'd expect a pattern synonym to have a clear "target type". > This is what I mean by modularity: no matter how complicated the right hand side of the pattern synonym, I want the client (of the library defining the pattern synonym) to be able to use it by knowing only its type -- just like he can for a function exported by a library. Yes, that's certainly a valid goal. Ok, for now, let's try to summarize: Every (bidirectional) pattern actually has two types, an "expression type" and a "pattern type". If I understand your proposal correctly, you're saying that pattern type signatures should allow the user specify the pattern type, because the expression type should in general be easy to infer. So I should be able to say {{{ pattern P :: T Bool b pattern P = MkT True }}} or for my original example {{{ pattern C :: Int -> Maybe a pattern C x = Y (Just x) }}} So perhaps GHCi should print both types rather than only the expression type on `:t`, something like: {{{ GHCi> :t C pattern C :: Int -> Maybe a C :: Int -> Maybe Int GHCi> :t P pattern P :: T Bool b P :: T Bool Bool }}} And perhaps for consistency even for normal data constructors? {{{ GHCi> :t MkT pattern MkT :: a -> T a b MkT :: a -> T a Bool }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 22:13:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 22:13:16 -0000 Subject: [GHC] #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory In-Reply-To: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> References: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> Message-ID: <063.c5f282b4bd8f46755115a7007fba6ee5@haskell.org> #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory ---------------------------------------+----------------------------------- Reporter: wmarshall | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 ezyang): Proposed patch: {{{ diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index 2c71967..93edf05 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1261,6 +1261,10 @@ runPhase (RealPhase SplitAs) _input_fn dflags liftIO $ createDirectoryIfMissing True split_odir + -- we create directories for the object file, because it + -- might be a hierarchical module. + liftIO $ createDirectoryIfMissing True (takeDirectory output_fn) + -- remove M_split/ *.o, because we're going to archive M_split/ *.o -- later and we don't want to pick up any old objects. fs <- liftIO $ getDirectoryContents split_odir }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 22:30:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 22:30:50 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.f576eb02a63cf8c361ba8bebd7d25a41@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): I think that is roughly right, yes. But the pattern type you give above gives no clue that type refinement takes place when you match on it, and a client of `C` definitely needs to know that. I think we can print the type of `C` and `MkT` like this: {{{ GHCi> :t MkT MkT :: (b~Bool) => a -> T a b GHCi> :t C C :: (a~Int) => Int -> Maybe a GHCi> pattern D x = MkT (Just x) GHCi> :t D D :: (b~Bool) => a -> T (Maybe a) b }}} These types work nicely both in expressions and patterns. * In expressions they are precisely equivalent to `a -> T a Bool` and `Int -> Maybe Int` respectively. * In patterns, pattern matching binds evidence for the equality. In Gergo's terminology, matching against `MkT` "provides" `(b~Bool)`; this refinement is available in the case alternative. The pattern synonym D is a nice example: * The result type `T (Maybe a) b` says that `D` must only match types of that shape, i.e. where the first arg of `T` is a `Maybe`. * The `(b~Bool) =>` says that when you match on `D` you get that type refinement available in the case alternative. So this actually a single signature that tells you all you need to know, both for matching and for use in expressions. Good! (There is a twist for what Gergo calls "required" constraints, which arise in view patterns and literal patterns, but let's ignore that for now.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 22:35:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 22:35:51 -0000 Subject: [GHC] #8983: sync-all get should respect branches Message-ID: <045.2387548a5134286050979bbad60135c3@haskell.org> #8983: sync-all get should respect branches ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If I have ghc-7.8 checked out and I do a './sync-all get', I might expect the repositories that are retrieved would also be set for ghc-7.8. However, this does not currently appear to be the case. This may be a little trickier, since if you're on a topic branch but you are mostly based off of master, then 'sync-all get' will fail, since the topic branch in question won't exist. So we should probably fall back in some way, rather than fail if the specified branch is not available. At the very least, we should print a warning if we sync-all get, the main branch is not master but we checked out a copy of master in the subrepo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 10 22:48:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Apr 2014 22:48:52 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.daa664720eb3b940cb89f462a97d0876@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): Yeah, I'm going to try to fix both. As for the stats, on a perf build on GHC 7.8, I see: {{{ T3294 max_bytes_used 37702264 T4801 bytes_allocated 429277160 T3064 bytes_allocated 346679176 T6048 bytes_allocated 120594240 }}} In fact, some of these tests are presently failing validate on a clean branch for me. So it seems the only real problem here is T3294 (where we have almost doubled the max bytes used). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 01:16:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 01:16: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.41ae19187b88d260e73280b9d1db27a8@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by carter): i've rebased on top the 7.8.2 tip of 7.8 branch https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...rb_cpp_settings the failure matchup with using real GCC on OS X, wherein real GCC doesn't understand objective c, (plus the perf stat issues that are generally afoot on several platform) {{{ Unexpected results from: TEST="objc-hi objcpp-hi T5837 T3064 T4801 T6048" OVERALL SUMMARY for test run started at Thu Apr 10 19:10:37 2014 EDT 0:23:53 spent to go through 3920 total tests, which gave rise to 12853 test cases, of which 9276 were skipped 26 had missing libraries 3484 expected passes 61 expected failures 0 caused framework failures 0 unexpected passes 6 unexpected failures Unexpected failures: driver/objc objc-hi [exit code non-0] (normal) driver/objc objcpp-hi [exit code non-0] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 01:28:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 01:28:53 -0000 Subject: [GHC] #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory In-Reply-To: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> References: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> Message-ID: <063.436c939be7929d0fa03324b6c3e8b8fb@haskell.org> #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory ---------------------------------------+----------------------------------- Reporter: wmarshall | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 ezyang): {{{ From c7498bbdaa74dadd976c75c4e303c2050aa78277 Mon Sep 17 00:00:00 2001 From: "Edward Z. Yang" Date: Thu, 10 Apr 2014 18:28:11 -0700 Subject: [PATCH] Fix #8641, creating directories when we have stubs. Signed-off-by: Edward Z. Yang --- compiler/main/DriverPipeline.hs | 2 ++ testsuite/tests/driver/B042stub/C.hs | 6 ++++++ testsuite/tests/driver/Makefile | 8 ++++++++ testsuite/tests/driver/all.T | 5 +++++ 4 files changed, 21 insertions(+) create mode 100644 testsuite/tests/driver/B042stub/C.hs diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index 2c71967..2816c94 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1259,6 +1259,7 @@ runPhase (RealPhase SplitAs) _input_fn dflags osuf = objectSuf dflags split_odir = base_o ++ "_" ++ osuf ++ "_split" + -- this also creates the hierarchy liftIO $ createDirectoryIfMissing True split_odir -- remove M_split/ *.o, because we're going to archive M_split/ *.o @@ -1469,6 +1470,7 @@ runPhase (RealPhase MergeStub) input_fn dflags = do PipeState{maybe_stub_o} <- getPipeState output_fn <- phaseOutputFilename StopLn + liftIO $ createDirectoryIfMissing True (takeDirectory output_fn) case maybe_stub_o of Nothing -> panic "runPhase(MergeStub): no stub" diff --git a/testsuite/tests/driver/B042stub/C.hs b/testsuite/tests/driver/B042stub/C.hs new file mode 100644 index 0000000..73f069c --- /dev/null +++ b/testsuite/tests/driver/B042stub/C.hs @@ -0,0 +1,6 @@ +{-# LANGUAGE ForeignFunctionInterface #-} +module B042stub.C where + +foreign export ccall foo :: IO () +foo :: IO () +foo = return () diff --git a/testsuite/tests/driver/Makefile b/testsuite/tests/driver/Makefile index 7673713..3603bb6 100644 --- a/testsuite/tests/driver/Makefile +++ b/testsuite/tests/driver/Makefile @@ -222,6 +222,14 @@ test042: "$(TEST_HC)" $(TEST_HC_OPTS_NO_RECOMP) -v0 --make B042/C.hs -odir obj042 test -f obj042/B042/C$(OBJSUFFIX) +# test -odir with stubs +test042stub: + $(RM) -rf obj042stub + mkdir obj042stub + $(RM) B042stub/C.hi + "$(TEST_HC)" $(TEST_HC_OPTS_NO_RECOMP) -v0 --make B042stub/C.hs -odir obj042stub + test -f obj042stub/B042stub/C$(OBJSUFFIX) + # test -hidir test043: $(RM) -f B043/C$(OBJSUFFIX) diff --git a/testsuite/tests/driver/all.T b/testsuite/tests/driver/all.T index aa4bc9b..ed0ce0f 100644 --- a/testsuite/tests/driver/all.T +++ b/testsuite/tests/driver/all.T @@ -142,6 +142,11 @@ test('driver042', run_command, ['$MAKE -s --no-print-directory test042']) +test('driver042stub', + extra_clean(['B042stub/C.hi', 'obj042stub/B042stub/C.o', 'obj042stub/B042stub/', 'obj042stub/']), + run_command, + ['$MAKE -s --no-print-directory test042stub']) + test('driver043', extra_clean(['B043/C.hi', 'B043/C.o', 'hi043/B043/C.hi', 'hi043/B043', 'hi043']), -- 1.8.3.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 01:57:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 01:57:12 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles Message-ID: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------------+------------------------------- Reporter: haasn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- When trying to build acme-schoenfinkel (as an example), I came across an error like this: {{{ Control/Category/Schoenfinkel.hs:66:48: Could not coerce from ?cat (cat b c, b) c? to ?cat (WrappedSchoenfinkel cat b c, b) c? because ?cat (cat b c, b) c? and ?cat (WrappedSchoenfinkel cat b c, b) c? are different types. arising from the coercion of the method ?app? from type ?forall b c. cat (cat b c, b) c? to type ?forall b c. WrappedSchoenfinkel cat (WrappedSchoenfinkel cat b c, b) c? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (ArrowApply (WrappedSchoenfinkel cat)) }}} It was not immediately clear to me as a user that this was caused due to it wanting GNT which was now being blocked by type roles (rightfully so, as this instance allows UnsafeCoerce!), and beyond that, what the specific rule that triggered this was. In this case the failure is due to ?WrappedSchoenfinkel cat b c? not being nominally equal to ?cat b c?, in the type ?(WrappedSchoenfinkel cat b c, b)?, which is required to be nominally equal to ?(cat b c, b)? because it's used as a parameter to the variable ?cat?. Printing a location breakdown and context information similar to this to the user would help understanding and debugging roles a lot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 01:59:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 01:59:35 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.c9e6df9eea23929f77f262af0c3d7a4e@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles --------------------------------------------+------------------------------ Reporter: haasn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by haasn): More specifically, the exact type that causes a problem is ?WrappedSchoenfinkel cat? and ?cat? not being nominally equal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 04:11:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 04:11:08 -0000 Subject: [GHC] #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory In-Reply-To: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> References: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> Message-ID: <063.ba061c13eab302f154eabc78d1cfc6eb@haskell.org> #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory ---------------------------------------+----------------------------------- Reporter: wmarshall | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 Edward Z. Yang ): In [changeset:"c7498bbdaa74dadd976c75c4e303c2050aa78277/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c7498bbdaa74dadd976c75c4e303c2050aa78277" Fix #8641, creating directories when we have stubs. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 04:14:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 04:14:01 -0000 Subject: [GHC] #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory In-Reply-To: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> References: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> Message-ID: <063.1899d296f43b1b37ae896618e238a125@haskell.org> #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory ---------------------------------------+----------------------------------- Reporter: wmarshall | Owner: ezyang Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 ezyang): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 05:37:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 05:37:05 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.b799153aca3490c0426ee0826a5b7f27@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): I looked at the context of "The closures stored in the indirection tables are tagged, which means that if the code expects an untagged closure, we need an extra instruction to deal with it", and noticed that the only reason we were untagging them was because the GC functions stg_gc_enter_1 and stg_gc_fun require 'node' to be untagged. So clearly, we should just have specialized versions of these functions which untag their argument. Actually, we can do even better: if we're making specialized versions, we can sidestep performing the load in code, so we have the invariant that for static closures, the node is a pointer to the static indirection. (Of course, this also means that we only get the savings from the heap checks of static closure entry code.) I'm implement this and see how much we save. As for overlapping the indirections with the data, there's something we can do even before that: since the closure that lives in memory doesn't have to be runnable, we can drop any fields that could be derived later. The counterbalance is that the initialization code gets a little more complex, but we're already case-splitting on the closure type, so it can't be too much worse. I'll also implement this and see how much better we do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 05:56:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 05:56:28 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.223cd1cd9fba01c6d99142b4bde12ac3@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): > I think that is roughly right, yes. But the pattern type you give above gives no clue that type refinement takes place when you match on it, and a client of `C` definitely needs to know that. That's why I proposed to show both types, but ... > I think we can print the type of `C` and `MkT` like this: > {{{ > GHCi> :t MkT > MkT :: (b~Bool) => a -> T a b > > GHCi> :t C > C :: (a~Int) => Int -> X Maybe a > > GHCi> pattern D x = MkT (Just x) > GHCi> :t D > D :: (b~Bool) => a -> T (Maybe a) b > }}} > These types work nicely both in expressions and patterns. Yes, I'm certainly happy with this as well. In fact, I had briefly considered making this suggestion. (I think back in GHC 6, GADT constructor types were actually displayed using a similar syntax.) My only worry is that it's slightly subtle that in these cases (where it's a type signature for a constructor or pattern synonym), inlining an equality constraint makes a difference, whereas for expressions it doesn't. But I guess that having two different type signatures printed wouldn't be any easier to understand. > The pattern synonym D is a nice example: > * The result type `T (Maybe a) b` says that `D` must only match types of that shape, i.e. where the first arg of `T` is a `Maybe`. > * The `(b~Bool) =>` says that when you match on `D` you get that type refinement available in the case alternative. > > So this actually a single signature that tells you all you need to know, both for matching and for use in expressions. Good! Yes, ok. > I should mention that internally the type of a GADT constructor like `MkT` really is as displayed here, namely `MkT :: (b~Bool) => a -> T a b`. Also good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 05:59:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 05:59:45 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.f0a0e78bccd7dde9ae6dd1225e125337@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): Oh, I forgot. What does this then imply for explicit type signature on pattern synonyms? Do you propose to still allow {{{ pattern D :: a -> T (Maybe a) b pattern D x = MkT (Just x) }}} (arguing that the "expression type" is easy to infer) or should the user also be forced to write {{{ pattern D :: (b ~ Bool) => a -> T (Maybe a) b pattern D x = MkT (Just x) }}} ? I think the latter would certainly be more consistent then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 06:48:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 06:48:59 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.9189a6dd767ee79e0ae21b8443991f92@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1 Resolution: fixed | 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 Lemming): Replying to [comment:12 simonpj]: > Who else has come across this? I encountered the bug when working on the tfp package. I could fix one problem within the package using the one-equation type family work-around. But the bug also affected the dependending llvm-tf package at several places. Thus I stopped working around and this means, that there might be more yet unseen places where it causes problems. Before a new release I would like very much to get a "nightly snapshot build" or "release candidate" for testing on 64-bit Linux. Otherwise I am afraid that the bugfix causes other subtle problems that will be part of 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 06:53:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 06:53:50 -0000 Subject: [GHC] #8968: Pattern synonyms and GADTs In-Reply-To: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> References: <047.5ccbe5e4c936202b9335f498db73d62e@haskell.org> Message-ID: <062.dff3a037f95f6dd7c9b00016d08f94a8@haskell.org> #8968: Pattern synonyms and GADTs ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Yes, I think it would have to be the latter. Several open issues remain: * We need pattern signatures. The workaround (of a signature embedded in the pattern) doesn't work too well for these more complicated types. * In fact having signatures embedded in a pattern synonym is problematic, because signatures behave differently in patterns and in terms. {{{ g x = Just x :: Maybe a f (Just x :: Maybe a) = x }}} In `g`, the type signature is implicitly quantified, so it really means `Just x :: forall a. Maybe a`, and the definition will therefore be rejected. But in the definition of `f`, the 'a' in the pattern is a ''binding'' occurrence, that scopes over the RHS; there is no implicit quantification. I'm inclined simply to disallow signature in the RHS of a pattern synonym. * We have no good syntax for the required/provided issue. I thought this was written up on the [wiki:PatternSynonyms Pattern Synonym wiki page] but it isn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 06:58:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 06:58:42 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.4cc93a1506cdc2007d3e54f3f7a09b65@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): The fix is merged on the 7.8.2 branch, so you can build it and try. I don't know if anyone has a pre-built binary distribution for your platform though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 07:01:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 07:01:00 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.454b9f9573e9efadace018a0a9f32dc1@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles --------------------------------------------+------------------------------ Reporter: haasn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by simonpj: Old description: > When trying to build acme-schoenfinkel (as an example), I came across an > error like this: > > {{{ > Control/Category/Schoenfinkel.hs:66:48: > Could not coerce from ?cat (cat b c, > b) c? to ?cat (WrappedSchoenfinkel cat b > c, b) c? > because ?cat (cat b c, b) c? and ?cat (WrappedSchoenfinkel cat b c, > b) c? are different types. > arising from the coercion of the method ?app? from type > ?forall b c. cat (cat b c, b) c? to type > ?forall b c. > WrappedSchoenfinkel cat (WrappedSchoenfinkel cat b c, > b) c? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (ArrowApply > (WrappedSchoenfinkel cat)) > }}} > > It was not immediately clear to me as a user that this was caused due to > it wanting GNT which was now being blocked by type roles (rightfully so, > as this instance allows UnsafeCoerce!), and beyond that, what the > specific rule that triggered this was. > > In this case the failure is due to ?WrappedSchoenfinkel cat b c? not > being nominally equal to ?cat b c?, in the type ?(WrappedSchoenfinkel cat > b c, b)?, which is required to be nominally equal to ?(cat b c, b)? > because it's used as a parameter to the variable ?cat?. > > Printing a location breakdown and context information similar to this to > the user would help understanding and debugging roles a lot. New description: When trying to build acme-schoenfinkel (as an example), I came across an error like this: {{{ Control/Category/Schoenfinkel.hs:66:48: Could not coerce from ?cat (cat b c, b) c? to ?cat (WrappedSchoenfinkel cat b c, b) c? because ?cat (cat b c, b) c? and ?cat (WrappedSchoenfinkel cat b c, b) c? are different types. arising from the coercion of the method ?app? from type ?forall b c. cat (cat b c, b) c? to type ?forall b c. WrappedSchoenfinkel cat (WrappedSchoenfinkel cat b c, b) c? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (ArrowApply (WrappedSchoenfinkel cat)) }}} It was not immediately clear to me as a user that this was caused due to it wanting GNT which was now being blocked by type roles (rightfully so, as this instance allows UnsafeCoerce!), and beyond that, what the specific rule that triggered this was. In this case the failure is due to `WrappedSchoenfinkel cat b c` not being nominally equal to `cat b c`, in the type `(WrappedSchoenfinkel cat b c, b)`, which is required to be nominally equal to `(cat b c, b)` because it's used as a parameter to the variable `cat`. Printing a location breakdown and context information similar to this to the user would help understanding and debugging roles a lot. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 07:03:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 07:03:34 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.d2cc6bd549bc205191548591ba3e7e31@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles --------------------------------------------+------------------------------ Reporter: haasn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by simonpj: Old description: > When trying to build acme-schoenfinkel (as an example), I came across an > error like this: > > {{{ > Control/Category/Schoenfinkel.hs:66:48: > Could not coerce from ?cat (cat b c, > b) c? to ?cat (WrappedSchoenfinkel cat b > c, b) c? > because ?cat (cat b c, b) c? and ?cat (WrappedSchoenfinkel cat b c, > b) c? are different types. > arising from the coercion of the method ?app? from type > ?forall b c. cat (cat b c, b) c? to type > ?forall b c. > WrappedSchoenfinkel cat (WrappedSchoenfinkel cat b c, > b) c? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (ArrowApply > (WrappedSchoenfinkel cat)) > }}} > > It was not immediately clear to me as a user that this was caused due to > it wanting GNT which was now being blocked by type roles (rightfully so, > as this instance allows UnsafeCoerce!), and beyond that, what the > specific rule that triggered this was. > > In this case the failure is due to `WrappedSchoenfinkel cat b c` not > being nominally equal to `cat b c`, in the type `(WrappedSchoenfinkel cat > b c, b)`, which is required to be nominally equal to `(cat b c, b)` > because it's used as a parameter to the variable `cat`. > > Printing a location breakdown and context information similar to this to > the user would help understanding and debugging roles a lot. New description: When trying to build acme-schoenfinkel (as an example), I came across an error like this: {{{ Control/Category/Schoenfinkel.hs:66:48: Could not coerce from ?cat (cat b c, b) c? to ?cat (WrappedSchoenfinkel cat b c, b) c? because ?cat (cat b c, b) c? and ?cat (WrappedSchoenfinkel cat b c, b) c? are different types. arising from the coercion of the method ?app? from type ?forall b c. cat (cat b c, b) c? to type ?forall b c. WrappedSchoenfinkel cat (WrappedSchoenfinkel cat b c, b) c? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (ArrowApply (WrappedSchoenfinkel cat)) }}} It was not immediately clear to me as a user that this was caused due to it wanting GNT which was now being blocked by type roles (rightfully so, as this instance allows `UnsafeCoerce`!), and beyond that, what the specific rule that triggered this was. In this case the failure is due to `WrappedSchoenfinkel cat b c` not being nominally equal to `cat b c`, in the type `(WrappedSchoenfinkel cat b c, b)`, which is required to be nominally equal to `(cat b c, b)` because it's used as a parameter to the variable `cat`. Printing a location breakdown and context information similar to this to the user would help understanding and debugging roles a lot. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 07:16:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 07:16:52 -0000 Subject: [GHC] #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism Message-ID: <047.369cd023f51a0cded951f791a8f64164@haskell.org> #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Consider the following test case (I've tried hard to make it minimal, which unfortunately means there's not a lot of intuition left): {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, GADTs, TypeOperators #-} data X (xs :: [k]) = MkX data Y :: (k -> *) -> [k] -> * where MkY :: f x -> Y f (x ': xs) type family F (a :: [[*]]) :: * type instance F xss = Y X xss works :: Y X '[ '[ ] ] -> () works (MkY MkX) = () fails :: F '[ '[ ] ] -> () fails (MkY MkX) = () }}} This code compiles in GHC 7.6.3, but it fails in GHC 7.8.1 (both rc2 and the actual release) with the following error: {{{ TestCase.hs:14:8: Couldn't match kind ?k0? with ?*? Expected type: F '['[]] Actual type: Y t0 t1 In the pattern: MkY MkX In an equation for ?fails?: fails (MkY MkX) = () TestCase.hs:14:12: Couldn't match type ?t0? with ?X? ?t0? is untouchable inside the constraints (t1 ~ (x : xs)) bound by a pattern with constructor MkY :: forall (f :: k -> *) (x :: k) (xs :: [k]). f x -> Y f (x : xs), in an equation for ?fails? at TestCase.hs:14:8-14 Expected type: t0 x Actual type: X x In the pattern: MkX In the pattern: MkY MkX In an equation for ?fails?: fails (MkY MkX) = () }}} I'm puzzled that simply adding the type family invokation makes the type checker fail with a kind error, even though the type family itself itsn't kind-polymorphic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 07:18:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 07:18:31 -0000 Subject: [GHC] #8986: GHC panic while installing distributive library on Mac OS X Mavericks Message-ID: <046.b8996dc60dcf52ba9ff88c219d35b963@haskell.org> #8986: GHC panic while installing distributive library on Mac OS X Mavericks ------------------------------------+------------------------------------- Reporter: mvanier | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While trying to install Snap from cabal, the install failed while installing the distributive-0.4.3.1 library. Specifically, I got this: > cabal install distributive Resolving dependencies... [1 of 1] Compiling Main ( /var/folders/76/d5y5v4wx7ybccp__l44r5cg00000gn/T/distributive-0.4.3.1-16721/distributive-0.4.3.1/Setup.lhs, /var/folders/76/d5y5v4wx7ybccp__l44r5cg00000gn/T/distributive-0.4.3.1-16721/distributive-0.4.3.1/dist/setup/Main.o ) Linking /var/folders/76/d5y5v4wx7ybccp__l44r5cg00000gn/T/distributive-0.4.3.1-16721/distributive-0.4.3.1/dist/setup/setup ... Configuring distributive-0.4.3.1... Building distributive-0.4.3.1... Preprocessing library distributive-0.4.3.1... [1 of 2] Compiling Data.Distributive.Generic ( src/Data/Distributive/Generic.hs, dist/build/Data/Distributive/Generic.o ) [2 of 2] Compiling Data.Distributive ( src/Data/Distributive.hs, dist/build/Data/Distributive.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-compat-0.1.1.1 ... ghc: /Users/mvanier/Library/Haskell/ghc-7.6.3/lib/transformers- compat-0.1.1.1/lib/HStransformers-compat-0.1.1.1.o: Bad magic. Expected: feedfacf, got: feedface. ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): loadObj "/Users/mvanier/Library/Haskell/ghc-7.6.3/lib /transformers-compat-0.1.1.1/lib/HStransformers-compat-0.1.1.1.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install distributive-0.4.3.1 cabal: Error: some packages failed to install: distributive-0.4.3.1 failed during the building phase. The exception was: ExitFailure 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 08:05:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 08:05:06 -0000 Subject: [GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles In-Reply-To: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> References: <044.9146c0f21c1d5c0ac4fad078a63640bb@haskell.org> Message-ID: <059.4b5b2a38b325cc19c8b9864bb9c5f2c5@haskell.org> #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles --------------------------------------------+------------------------------ Reporter: haasn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Here's a small test case {{{ {-# LANGUAGE ConstraintKinds, GeneralizedNewtypeDeriving #-} module T8984 where class C a where app :: a (a Int) newtype N cat a b = MkN (cat a b) deriving( C ) -- The newtype coercion is N cat ~R cat }}} We try to prove `Coercible (cat (cat Int) (N cat (N cat Int))`. We simplify this (by newtype unrwrapping) to `Coercible (cat (cat Int)) (cat (N cat Int))`; and now we are stuck. {{{ T8984.hs:7:46: Could not coerce from ?cat a (cat a Int)? to ?cat a (N cat a Int)? because ?cat a (cat a Int)? and ?cat a (N cat a Int)? are different types. arising from the coercion of the method ?app? from type ?cat a (cat a Int)? to type ?N cat a (N cat a Int)? }}} An alternative strategy would be to see that the newtype axiom is over- applied, and instead decompose the application thus: {{{ Coercible (cat (cat Int) (N cat (N cat Int)) ==> (decompose application into two parts) Coercible cat (N cat), cat Int ~ N Cat int }}} Now the first constraint is soluble, but the second would say something like "cannot deduce `cat Int ~ N Cat Int`. Joachim, Richard, thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 11:05:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 11:05:26 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.4f259b2fd0fc630ce8958013608811ad@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): I started implementing this and printing through ``` IfaceDecl ``` directly as you suggested is the easier way and it turns out we don't really need to add any more information, all we need for printing properly is already there. Now before I go any further we need to discuss the approach I have taken and if it needs changing. Right now I'm exporting ``` pprIfaceDecl ``` from ``` IfaceSyn ``` and I've modified it to look like this ``` pprIfaceDecl :: Maybe ShowSub -> IfaceDecl -> SDoc ``` this allows us to decide how we print things, if the first argument is ``` Nothing ``` we print ``` IfaceDecl ``` the old way. This will polute the ``` IfaceDecl ``` printing function with stuff destined for GHCi printing but it has the advantage that there are a lot of places where the printing is the same and a lot of code from pprTyThing will no longer be necessary. Another aproach is to write a separate ``` IfaceDecl ``` printing function for use in GHCi, but while keeping things separate this will lead to a lot of duplication. If you think that I should take the second aproach, or another that I did not consider please tell me and I will implement it. Thank you, Andrei -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 13:32:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 13:32:39 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.2bc14943e77e24eba659fd2d6bf89bf5@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): We could also just use ``` tyThingToIfaceDecl ``` and keep printing ```TyThing`` using the existing code and just replace the type variables with the ones we extract from ``` IfaceDecl ``` . This fix would be just a few lines but it seems rather hackish and wasteful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 13:41:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 13:41:41 -0000 Subject: [GHC] #7908: InstanceSigs suggestion not accepted In-Reply-To: <048.16e7666fc7d089cc84c391ee087463e7@haskell.org> References: <048.16e7666fc7d089cc84c391ee087463e7@haskell.org> Message-ID: <063.0efec9b9393c39f79607822a4473b495@haskell.org> #7908: InstanceSigs suggestion not accepted -------------------------------------+------------------------------------ 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: -------------------------------------+------------------------------------ Changes (by edsko): * cc: edsko@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 14:08:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 14:08:41 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.a26bef35025335c5be55c7bf02866668@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): Replying to [comment:13 archblob]: > Right now I'm exporting ``` pprIfaceDecl ``` from ``` IfaceSyn ``` and I've modified it to look like this ``` pprIfaceDecl :: Maybe ShowSub -> IfaceDecl -> SDoc ``` this allows us to decide how we print things, if the first argument is ``` Nothing ``` we print ``` IfaceDecl ``` the old way. That sounds roughly right, but I'm not sure what you mean by "the old way". Really `pprIfaceDecl` should simply behave like `ppr_ty_thing` does today. Re comment 14, the point is to combine the pretty printing not to complicate the duplicate code! So let's not do that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 14:14:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 14:14:53 -0000 Subject: [GHC] #7908: InstanceSigs suggestion not accepted In-Reply-To: <048.16e7666fc7d089cc84c391ee087463e7@haskell.org> References: <048.16e7666fc7d089cc84c391ee087463e7@haskell.org> Message-ID: <063.f1ca8a6a6e4229b11725096b8ed7f226@haskell.org> #7908: InstanceSigs suggestion not accepted -------------------------------------+------------------------------------ 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: -------------------------------------+------------------------------------ Changes (by kosmikus): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 14:24:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 14:24:06 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.b6c49dbb6727c2b47e534c80f2b18b60@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): By the "old way" I mean that in most cases the output of ``` pprIfaceDecl ``` looks nothing like ``` ppr_ty_thing ```, so the way I described this would pe to leave ``` ppr = pprIfaceDecl Nothing ``` for the ``` Outputable ``` instance of ``` IfaceDecl ``` so that when using ``` --show-iface ``` nothing would change, also there is a lot more information printed by ``` pprIfaceDecl ``` than ``` ppr_ty_thing ```. So if you want the output of ``` pprIfaceDecl ``` to look like ``` ppr_ty_thing ``` I'm not sure what to do about the extra information that is now printed, and that will also affect the output of ``` --show-iface ``` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 14:36:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 14:36:42 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.8aee5748712aac47bcf477cf758612ed@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): Well, I'm talking a lot, but to summarize, my impression was that the current output format of ``` pprIfaceDecl ``` should also be kept, and just print differently when called from :info, but if that is not the case and if the format is amenable to change I will go ahead and make it look like ``` ppr_ty_thing ``` does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 15:08:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 15:08:28 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.0db91566d6e9930fea30cf7a0268d178@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Just for the record. Under 64bit windows (as described wiki:Building/Preparation/Windows/MSYS2) I get the "nm -p" output: {{{ derivedConstantMAX_Vanilla_REG C 000000000000000b }}} (without leading underscore) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 15:28:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 15:28:52 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception Message-ID: <044.4c21331b0c5897214741257d5027da6d@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception -----------------------------------+--------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- `reportWarning` and `reportError` doesn't force it's argument, so `ghc` panics when printing the message. To reproduce: {{{#!haskell test :: Q [Dec] test = do reportWarning undefined return [] }}} Output: {{{ main.hs:5:3: Warning:ghc: panic! (the 'impossible' happened) (GHC version 7.8.1 for x86_64-unknown-linux): Prelude.undefined Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The fix could be: {{{ --- a/compiler/typecheck/TcSplice.lhs +++ b/compiler/typecheck/TcSplice.lhs @@ -875,8 +875,8 @@ instance TH.Quasi (IOEnv (Env TcGblEnv TcLclEnv)) where ; let i = getKey u ; return (TH.mkNameU s i) } - qReport True msg = addErr (text msg) - qReport False msg = addWarn (text msg) + qReport True !msg = addErr (text msg) + qReport False !msg = addWarn (text msg) qLocation = do { m <- getModule ; l <- getSrcSpanM }}} But possibly it should `deepseq` the argument? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 15:31:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 15:31:15 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception In-Reply-To: <044.4c21331b0c5897214741257d5027da6d@haskell.org> References: <044.4c21331b0c5897214741257d5027da6d@haskell.org> Message-ID: <059.5af7f32325459eceee77df0e7db3fb29@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 Yuras): * cc: shumovichy@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 16:11:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 16:11:47 -0000 Subject: [GHC] #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism In-Reply-To: <047.369cd023f51a0cded951f791a8f64164@haskell.org> References: <047.369cd023f51a0cded951f791a8f64164@haskell.org> Message-ID: <062.941fbdb251442cbc46495c67cbf2fc23@haskell.org> #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.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 simonpj): Thank you. It's a palpable bug in the kind unifier. Working on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 16:16:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 16:16:39 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.78236302be23726ce857ee22c14a380c@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by maeder): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 16:18:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 16:18:54 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.3d0aeee5be6c45feeaf60241c43f28ed@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: libraries | Version: 7.8.1-rc2 (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: Blocking: | -------------------------------------+------------------------------------- Changes (by maeder): * milestone: 7.8.1 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 18:26:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 18:26:20 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.17aae93992f725ba79351226b895b5bc@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 awson): I've checked things on 32-bit linux. It suffers too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 19:30:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 19:30:58 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.54301786ab274b8e75732c307743b6cd@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Old description: > This bug is to track progress of removing HEAP_ALLOCED from GHC, > promising faster GC (especially for large/scattered heaps), as long as we > can keep the cost of indirections down. > > The relevant wiki article: > http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; > we are implementing method 2. Version 2 of the patchset is probably > correct. > > Blocking problems: > > * Properly handle the Windows DLL case (e.g. SRTs). We will probably have > to reorganize how the indirections are laid out. > > * ~~Make it work for GHCi linking of static objects.~~ Blocked on #2841, > I have it working for ELF, and can make it work for other platforms as > soon as I get relevant machines. > > * Bikeshed hs_main API changes (because closures are not valid prior to > RTS initialization, so you have to pass in an indirection instead) > > * Does not work with unloadObj (see comments below) > > Performance improvements possible: > > * ~~This patch introduces a lot of new symbols; ensure we are not unduly > polluting the symbol tables. (In particular, I think _static_closure > symbols can be made hidden).~~ I've eliminated all of these except for > the init symbols, which cross the stub object and assembly file boundary, > and so would need to be made invisible by the linker. > > * Don't pay for a double indirection when -fPIC is turned on. Probably > the easiest way to do this is to *not* bake in the indirections into > compiled code when it is -fPIC'd, and instead scribble over the GOT. > However, I don't know how to go backwards from a symbol to a GOT entry, > so we might need some heinous assembly hacks to get this working. > > * The old HEAP_ALLOCED is supposed to be pessimal on very large heaps. Do > some performance tests under those workloads. > > * Make sure the extra indirection is not causing any C-- optimizations to > stop firing (it might be, because I put it in as a literal CmmLoad) > > * Once an static thunk is updated, we can tag the indirection to let > other code segments to know about the good news. One way to do this is > have the update frame for a static indirection should have a reference to > the *indirection*, not the closure itself. However, this scheme will not > affect other static closures which have references to the thunk. > > * Closure tables should have their indirections short-circuited by the > initialization code. But maybe it is not worth the cost of telling the > RTS about the closure tables (also, they would need to be made > writeable). > > * We are paying an indirection when a GC occurs when the closure is not > in R1. According to the wiki page, technically this is not needed, but I > don't know how to eliminate references to the closure itself from > stg_gc_fun. > > * ~~Save tags inside the indirection tables, so that we don't spend > instructions retagging after the following the indirection.~~ Done. > > * ~~Improve static indirection and stable pointer registration, avoiding > binary bloat from `__attribute(constructor)__` stubs.~~ After discussing > this with some folks, it seems that there isn't really a portable way to > do this when we are using the system dynamic linker to load libraries at > startup. The problem is that we need to somehow get a list of all the > GHC-compiled libraries which got loaded, and really the easiest way to > get that is to just build it ourselves. > > * ~~Need to implement a new megablock tracking structure so we can > free/check for lost blocks~~. Now that efficient lookup is not necessary, > perhaps we can write-optimize the megablock tracking structures. > > Speculative improvements: > > * Now that static lives in a block, can we GC them like we GC normal > data? This would be beneficial for static thunks, which now can have > their indirections completely removed; reverting CAFs may be somewhat > tricky, however. > > * Now that HEAP_ALLOCED is greatly simplified, can we further simply some > aspects of the GC? At the very least, we ought to be able to make > megablock allocation cheaper, by figuring out how to remove the > spinlocks, etc. > > * Another possibility is to adopt a hybrid approach, where we manually > lay out closures when compiling statically, and indirect when compiling > dynamically. In some sense, this gets the best of both worlds, since we > expect to not pay any extra cost for indirection due to PIC. New description: This bug is to track progress of removing HEAP_ALLOCED from GHC, promising faster GC (especially for large/scattered heaps), as long as we can keep the cost of indirections down. The relevant wiki article: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; we are implementing method 2. Version 2 of the patchset is probably correct. Blocking problems: * Properly handle the Windows DLL case (e.g. SRTs). We will probably have to reorganize how the indirections are laid out. * ~~Make it work for GHCi linking of static objects.~~ Blocked on #2841, I have it working for ELF, and can make it work for other platforms as soon as I get relevant machines. * Bikeshed hs_main API changes (because closures are not valid prior to RTS initialization, so you have to pass in an indirection instead) * Does not work with unloadObj (see comments below) Performance improvements possible: * ~~This patch introduces a lot of new symbols; ensure we are not unduly polluting the symbol tables. (In particular, I think _static_closure symbols can be made hidden).~~ ~~I've eliminated all of these except for the init symbols, which cross the stub object and assembly file boundary, and so would need to be made invisible by the linker.~~ I needed to make local info tables public. * Don't pay for a double indirection when -fPIC is turned on. Probably the easiest way to do this is to *not* bake in the indirections into compiled code when it is -fPIC'd, and instead scribble over the GOT. However, I don't know how to go backwards from a symbol to a GOT entry, so we might need some heinous assembly hacks to get this working. * The old HEAP_ALLOCED is supposed to be pessimal on very large heaps. Do some performance tests under those workloads. * Make sure the extra indirection is not causing any C-- optimizations to stop firing (it might be, because I put it in as a literal CmmLoad) * Once an static thunk is updated, we can tag the indirection to let other code segments to know about the good news. One way to do this is have the update frame for a static indirection should have a reference to the *indirection*, not the closure itself. However, this scheme will not affect other static closures which have references to the thunk. * Closure tables should have their indirections short-circuited by the initialization code. But maybe it is not worth the cost of telling the RTS about the closure tables (also, they would need to be made writeable). * We are paying an indirection when a GC occurs when the closure is not in R1. According to the wiki page, technically this is not needed, but I don't know how to eliminate references to the closure itself from stg_gc_fun. * ~~Save tags inside the indirection tables, so that we don't spend instructions retagging after the following the indirection.~~ Done. * ~~Improve static indirection and stable pointer registration, avoiding binary bloat from `__attribute(constructor)__` stubs.~~ After discussing this with some folks, it seems that there isn't really a portable way to do this when we are using the system dynamic linker to load libraries at startup. The problem is that we need to somehow get a list of all the GHC-compiled libraries which got loaded, and really the easiest way to get that is to just build it ourselves. * ~~Need to implement a new megablock tracking structure so we can free/check for lost blocks~~. Now that efficient lookup is not necessary, perhaps we can write-optimize the megablock tracking structures. Speculative improvements: * Now that static lives in a block, can we GC them like we GC normal data? This would be beneficial for static thunks, which now can have their indirections completely removed; reverting CAFs may be somewhat tricky, however. * Now that HEAP_ALLOCED is greatly simplified, can we further simply some aspects of the GC? At the very least, we ought to be able to make megablock allocation cheaper, by figuring out how to remove the spinlocks, etc. * Another possibility is to adopt a hybrid approach, where we manually lay out closures when compiling statically, and indirect when compiling dynamically. In some sense, this gets the best of both worlds, since we expect to not pay any extra cost for indirection due to PIC. -- Comment (by ezyang): Great news: with overlapping/compressed static closure representation, binary size overall is now less than it used to be! The downside is that I still need to collect static closures together away from their definition, which means that I now need to export symbols local info tables (which I know we'd previously been keeping local to reduce the number of symbols). Remaining tasks: unloadObj support and T3294 performance debugging.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 20:11:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 20:11:05 -0000 Subject: [GHC] #8988: Documentation build fails if GHCi is unavailable Message-ID: <047.4e32c2ffd98d48e7ad6de5d06c23433e@haskell.org> #8988: Documentation build fails if GHCi is unavailable -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Operating System: Linux Keywords: | Type of failure: Building GHC Architecture: arm | failed Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Joachim Breitner [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-March/024730.html reported] that the documentation fails to build on Debian armhf: {{{ 0% ( 0 / 5) in 'WwLib' 0% ( 0 / 2) in 'DmdAnal' 0% ( 0 / 2) in 'WorkWrap' compiler/typecheck/TcSplice.lhs-boot:29:1: TcSplice.tcTopSpliceExpr is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:37:1: TcSplice.runMetaE is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:38:1: TcSplice.runMetaP is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:39:1: TcSplice.runMetaT is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:40:1: TcSplice.runMetaD is exported by the hs-boot file, but not exported by the module 67% ( 2 / 3) in 'CmmPipeline' 0% ( 0 / 3) in 'StgCmmHpc' 0% ( 0 / 13) in 'PrelInfo' 0% ( 0 / 4) in 'StgCmmCon' 0% ( 0 / 2) in 'StgCmmExpr' 0% ( 0 / 6) in 'StgCmmBind' 0% ( 0 / 2) in 'CmmParse' 0% ( 0 / 2) in 'StgCmm' 5% ( 9 /175) in 'TcRnMonad' make[2]: *** [compiler/stage2/doc/html/ghc/ghc.haddock] Error 1 }}} The attached patch fixes this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 22:03:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 22:03:16 -0000 Subject: [GHC] #8943: Add System.Process.createPipe In-Reply-To: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> References: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> Message-ID: <059.e6657312cfc40f5e55aa89bda1e31ee8@haskell.org> #8943: Add System.Process.createPipe --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/process | 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 refold): I get the following error on Windows: {{{ [2 of 3] Compiling System.Process ( System\Process.hs, dist\build\System\Proce ss.o ) C:\program files (x86)\haskell platform\2013.2.0.0\mingw\bin\..\lib\gcc\mingw32\ 4.5.2\..\..\..\..\include\io.h:64:1: parse error on input `{' }}} After renaming `System\Process.hs` to `.hsc` I get: {{{ [2 of 3] Compiling System.Process ( dist\build\System\Process.hs, dist\build\S ystem\Process.o ) SystemProcess.hsc:921:18: Ambiguous occurrence `fdToHandle' It could refer to either `System.Process.fdToHandle', defined at SystemProcess.hsc:926:1 or `System.Process.Internals.fdToHandle', imported from `System.Process.Internals' at SystemP rocess.hsc:69:1-31 (and originally defined in `GHC.IO.Handle.FD') SystemProcess.hsc:922:19: Ambiguous occurrence `fdToHandle' It could refer to either `System.Process.fdToHandle', defined at SystemProcess.hsc:926:1 or `System.Process.Internals.fdToHandle', imported from `System.Process.Internals' at SystemP rocess.hsc:69:1-31 (and originally defined in `GHC.IO.Handle.FD') }}} After removing the `fdToHandle` function and fixing the call sites everything compiles fine, modulo warnings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 11 23:53:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Apr 2014 23:53:35 -0000 Subject: [GHC] #8943: Add System.Process.createPipe In-Reply-To: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> References: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> Message-ID: <059.deef3df166107e2d7a8f015d9827151a@haskell.org> #8943: Add System.Process.createPipe --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/process | 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 refold): I've attached an updated version of the patch that compiles for me on GHC 7.6.3. Can I help with anything else (e.g. running tests)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 01:18:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 01:18:05 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.11048decb6c245d9099535905d667a33@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Comment (by cjwatson): I finally managed to figure this out, thanks in part to some debugging tips from `slyfox` on `#ghc`. The two necessary patches are attached, and I'd appreciate review. With this, I've been able to completely bootstrap GHC 7.8 on this architecture, albeit without GHCi for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 01:30:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 01:30:33 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.6baaa30830f1d5150b145acd1e0886bb@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Comment (by ezyang): Wow, nice catch! Are there any other places where we are improperly declaring null argument lists? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 01:44:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 01:44:00 -0000 Subject: [GHC] #8989: nofib should record and report more fine-grained binary size information Message-ID: <045.a72571a710bc9f843651efa8f20fa51e@haskell.org> #8989: nofib should record and report more fine-grained binary size information -----------------------------------------+--------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- Probably by section would be best; this way we can distinguish between increases in code size, as opposed to increases from other sources. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 02:20:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 02:20:23 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.528c54d3f64361680e0fadec4672ec96@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Changes (by thoughtpolice): * status: new => patch * milestone: => 7.8.3 Comment: Excellent work Colin! I'll put this in for 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 09:28:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 09:28:55 -0000 Subject: [GHC] #8943: Add System.Process.createPipe In-Reply-To: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> References: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> Message-ID: <059.0253ca230ac6c4a461572e7661f5c3da@haskell.org> #8943: Add System.Process.createPipe --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/process | 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): Replying to [comment:4 refold]: > I've attached an updated version of the patch that compiles for me on GHC 7.6.3. Can I help with anything else (e.g. running tests)? If you could look into the issue Simon mentioned above (which is a Windows-only issue) that would be great. As for testing, if you like you can apply this patch locally and try to have Cabal use this version of `createPipe` instead of the one we have in the cabal repo, tht would be very helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 10:48:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 10:48:08 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.cd7b4f298fb97a214ea49c811f81a810@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Comment (by cjwatson): Replying to [comment:2 ezyang]: > Wow, nice catch! Are there any other places where we are improperly declaring null argument lists? I wouldn't like to categorically say no, because I don't know GHC anywhere near well enough for that. :-) The best I can do is to say that nothing else impeded the bootstrap on this architecture ... I did find a couple of related problems: * While using an empty parameter list is better than a wrong parameter list, it's technically an obsolescent feature in C11, and the proper fix is to generate a correct prototype. The compiler hacking for this is beyond me. * There are a couple of uses of (at least) `debugBelch` in `rts/*.cmm`, which have a similar problem: if you try to run the compiler on ppc64el with `-Da`, for instance, it crashes because the call to `debugBelch` in `stg_ap_0_fast` corrupts the caller's stack, as it didn't realise it was calling a varargs function and so didn't allocate enough stack space. There's a `debugBelch2` workaround in `libraries/base` for the same kind of problem; the RTS probably needs to do something similar. Generating correct prototypes in the compiler would fix this problem too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 11:00:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 11:00:26 -0000 Subject: [GHC] #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) Message-ID: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Example: {{{ [ezyang at hs01 compiler]$ cat T6048.comp.stats /home/hs01/ezyang/ghc-compalloc/inplace/lib/bin/ghc-stage2 -B/home/hs01/ezyang/ghc-compalloc/inplace/lib -fforce-recomp -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable [("bytes allocated", "119871672") ,("num_GCs", "100") ,("average_bytes_used", "4388904") ,("max_bytes_used", "12539576") ,("num_byte_usage_samples", "7") ,("peak_megabytes_allocated", "27") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "0.09") ,("mutator_wall_seconds", "0.10") ,("GC_cpu_seconds", "0.15") ,("GC_wall_seconds", "0.15") ] [ezyang at hs01 compiler]$ rm T6048.hi [ezyang at hs01 compiler]$ '/home/hs01/ezyang/ghc-compalloc/inplace/bin/ghc- stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable -RTS [ezyang at hs01 compiler]$ cat T6048.comp.stats /home/hs01/ezyang/ghc-compalloc/inplace/lib/bin/ghc-stage2 -B/home/hs01/ezyang/ghc-compalloc/inplace/lib -fforce-recomp -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable [("bytes allocated", "121022912") ,("num_GCs", "100") ,("average_bytes_used", "4022069") ,("max_bytes_used", "11224944") ,("num_byte_usage_samples", "7") ,("peak_megabytes_allocated", "25") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "0.09") ,("mutator_wall_seconds", "0.11") ,("GC_cpu_seconds", "0.15") ,("GC_wall_seconds", "0.14") ] }}} It's a slight but present difference: I noticed because one of the perf tests was failing on an initial run of the test suite, but passing when I re-ran it. There are two possible bugs here. One is that our implementation of `-fforce-recomp` is buggy and we shouldn't be reading in the hi file at all if `-fforce-recomp` is on; the other is that we should always clean up interface files before running one of these perf tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 11:21:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 11:21:59 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.ca08531f8a6a4d2571a84d7145bdf154@haskell.org> #8978: Type synonyms in class associated types behave strangely ----------------------------------------------+---------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1 Resolution: fixed | 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 Lemming): Replying to [comment:17 simonpj]: > The fix is merged on the 7.8.2 branch, so you can build it and try. I don't know if anyone has a pre-built binary distribution for your platform though. I can confirm that the problems are gone with the ghc-7.8.1.20140410 built by Michael Snoyman. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 11:29:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 11:29:19 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.650690e2d1fa47c26e5ef8c1c01c835b@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): One more progress report (as before, selection of outliers as well as overall figures), after having rebased onto HEAD: {{{ bernouilli -0.5% -0.0% -9.1% -9.1% 0.0% circsim -0.5% -0.0% +4.5% +4.5% +21.7% cryptarithm1 -0.5% +0.0% +7.6% +7.6% +100.0% lcss -0.5% -0.0% -8.3% -8.3% +1.9% wheel-sieve2 -0.5% -0.0% -9.1% -9.1% +2.1% -------------------------------------------------------------------------------- Min -0.9% -12.0% -9.1% -9.1% -5.2% Max -0.4% +0.4% +7.6% +7.6% +100.0% Geometric Mean -0.5% -0.5% -1.8% -1.8% +9.0% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 12:12:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 12:12:54 -0000 Subject: [GHC] #8925: :print and :sprint sometimes fully evaluates strings In-Reply-To: <045.158e5823a1b625f26a808590111b756b@haskell.org> References: <045.158e5823a1b625f26a808590111b756b@haskell.org> Message-ID: <060.dbd43fb96544ba969a1d1332e181ac9b@haskell.org> #8925: :print and :sprint sometimes fully evaluates strings -------------------------------------+------------------------------------ Reporter: soapie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by soapie): * version: 7.6.3 => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 12:41:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 12:41:24 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.41c55c83b3e017ae9eca9b88d3c08c10@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Changes (by slyfox): * cc: slyfox@? (added) Comment: Great catch indeed! As for prototype mismatch there is a very heavy hammer I tried a while ago: ./configure --enable-unrefisterised CFLAGS=-flto LDFLAGS=-flto It dies in Cmm in things like 'memset' being 'const' incompatible with stdlib.h thing, but in general very nice thing to check for bugs repository-wide. And find real problems. I'll try that once again and post most relevant bits. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 13:12:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 13:12:28 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" In-Reply-To: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> References: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> Message-ID: <063.03cc7636a07b5f72af1007f0dc6a1fc2@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by adinapoli): Hi guys, I've installed GHC 7.8.1 (official release) and I'm still experiencing this on my 2009 MacPro (with Mavericks). This is the output of "cabal install -v3 -j", hoping we could extract some meaningful info out of this. {{{ Using a sandbox located at /Users/adinapoli/programming/haskell/Tidal/.cabal-sandbox Searching for ghc in path. Found ghc at /Users/adinapoli/Library/Haskell/current/bin/ghc ("/Users/adinapoli/Library/Haskell/current/bin/ghc",["--numeric-version"]) /Users/adinapoli/Library/Haskell/current/bin/ghc is version 7.8.1 looking for tool ghc-pkg near compiler in /Users/adinapoli/Library/Haskell/current/bin found ghc-pkg in /Users/adinapoli/Library/Haskell/current/bin/ghc-pkg ("/Users/adinapoli/Library/Haskell/current/bin/ghc-pkg",["--version"]) /Users/adinapoli/Library/Haskell/current/bin/ghc-pkg is version 7.8.1 ("/Users/adinapoli/Library/Haskell/current/bin/ghc",["--supported- languages"]) ("/Users/adinapoli/Library/Haskell/current/bin/ghc",["--info"]) The package database already exists: /Users/adinapoli/programming/haskell/Tidal/.cabal-sandbox/x86_64-osx- ghc-7.8.1-packages.conf.d Reading available packages... Reading available packages... Reading installed packages... ("/Users/adinapoli/Library/Haskell/current/bin/ghc-pkg",["dump ","--package-db=/Users/adinapoli/programming/haskell/Tidal/.cabal- sandbox/x86_64-osx-ghc-7.8.1-packages.conf.d","-v0"]) ("/Users/adinapoli/Library/Haskell/current/bin/ghc",["--print-libdir"]) Reading installed packages... ("/Users/adinapoli/Library/Haskell/current/bin/ghc-pkg",["dump","-- global","-v0"]) ("/Users/adinapoli/Library/Haskell/current/bin/ghc-pkg",["dump ","--package-db=/Users/adinapoli/programming/haskell/Tidal/.cabal- sandbox/x86_64-osx-ghc-7.8.1-packages.conf.d","-v0"]) ("/Users/adinapoli/Library/Haskell/current/bin/ghc",["--print-libdir"]) Reading available packages... Choosing modular solver. Resolving dependencies... [__0] trying: tidal-0.3.5 (user goal) [__1] trying: base-4.7.0.0/installed-0e1... (dependency of tidal-0.3.5) [__2] trying: rts-1.0/installedbuil... (dependency of base-4.7.0.0 /installed-0e1...) [__3] trying: integer-gmp-0.5.1.0/installed-557... (dependency of base-4.7.0.0/installed-0e1...) [__4] trying: ghc-prim-0.3.1.0/installed-68a... (dependency of base-4.7.0.0/installed-0e1...) [__5] trying: bytestring-0.10.4.0/installed-294... (dependency of tidal-0.3.5) [__6] trying: deepseq-1.3.0.2/installed-355... (dependency of bytestring-0.10.4.0/installed-294...) [__7] trying: array-0.5.0.0/installed-867... (dependency of deepseq-1.3.0.2/installed-355...) [__8] trying: binary-0.7.1.0/installed-619... (dependency of tidal-0.3.5) [__9] trying: mersenne-random-pure64-0.2.0.4 (dependency of tidal-0.3.5) [_10] trying: mersenne-random-pure64-0.2.0.4:-small_base [_11] trying: random-1.0.1.1 (dependency of mersenne-random- pure64-0.2.0.4:-small_base) [_12] trying: old-time-1.1.0.2/installed-9cc... (dependency of mersenne- random-pure64-0.2.0.4:-small_base) [_13] trying: old-locale-1.0.0.6/installed-ab7... (dependency of old- time-1.1.0.2/installed-9cc...) [_14] trying: transformers-0.3.0.0/installed-aab... (dependency of tidal-0.3.5) [_15] trying: mtl-2.1.3.1 (dependency of tidal-0.3.5) [_16] trying: text-1.1.0.1 (dependency of tidal-0.3.5) [_17] trying: text-1.1.0.1:-integer-simple [_18] trying: text-1.1.0.1:-developer [_19] trying: text-1.1.0.1:!test [_20] trying: websockets-0.8.2.1 (dependency of tidal-0.3.5) [_21] trying: websockets-0.8.2.1:!test [_22] trying: entropy-0.2.2.4 (dependency of websockets-0.8.2.1) [_23] trying: unix-2.7.0.1/installed-a02... (dependency of entropy-0.2.2.4) [_24] trying: SHA-1.6.4 (dependency of websockets-0.8.2.1) [_25] trying: SHA-1.6.4:-test [_26] trying: SHA-1.6.4:-exe [_27] trying: SHA-1.6.4:+decoderinterface [_28] trying: directory-1.2.1.0/installed-8da... (dependency of SHA-1.6.4) [_29] trying: filepath-1.3.0.2/installed-ea3... (dependency of directory-1.2.1.0/installed-8da...) [_30] trying: network-2.4.2.2 (dependency of websockets-0.8.2.1) [_31] trying: network-2.4.2.2:!test [_32] trying: io-streams-1.1.4.2 (dependency of websockets-0.8.2.1) [_33] trying: io-streams-1.1.4.2:-nointeractivetests [_34] trying: io-streams-1.1.4.2:!test [_35] trying: zlib-bindings-0.1.1.5 (dependency of io-streams-1.1.4.2) [_36] trying: zlib-bindings-0.1.1.5:!test [_37] trying: zlib-0.5.4.1 (dependency of zlib-bindings-0.1.1.5) [_38] trying: vector-0.10.9.1 (dependency of io-streams-1.1.4.2) [_39] trying: vector-0.10.9.1:-unsafechecks [_40] trying: vector-0.10.9.1:-internalchecks [_41] trying: vector-0.10.9.1:+boundschecks [_42] trying: primitive-0.5.2.1 (dependency of io-streams-1.1.4.2) [_43] trying: case-insensitive-1.2.0.0 (dependency of websockets-0.8.2.1) [_44] trying: case-insensitive-1.2.0.0:!bench [_45] trying: case-insensitive-1.2.0.0:!test [_46] trying: blaze-builder-0.3.3.2 (dependency of websockets-0.8.2.1) [_47] trying: base64-bytestring-1.0.0.1 (dependency of websockets-0.8.2.1) [_48] trying: base64-bytestring-1.0.0.1:!test [_49] trying: attoparsec-0.11.2.1 (dependency of websockets-0.8.2.1) [_50] trying: attoparsec-0.11.2.1:-developer [_51] trying: attoparsec-0.11.2.1:!bench [_52] trying: attoparsec-0.11.2.1:!test [_53] trying: scientific-0.2.0.2 (dependency of attoparsec-0.11.2.1) [_54] trying: scientific-0.2.0.2:!bench [_55] trying: scientific-0.2.0.2:!test [_56] trying: time-1.4.2/installed-b6e... (dependency of tidal-0.3.5) [_57] trying: containers-0.5.5.1/installed-b57... (dependency of tidal-0.3.5) [_58] trying: colour-2.3.3 (dependency of tidal-0.3.5) [_59] trying: hashable-1.2.1.0 (dependency of tidal-0.3.5) [_60] trying: hashable-1.2.1.0:-sse41 [_61] trying: hashable-1.2.1.0:+sse2 [_62] trying: hashable-1.2.1.0:+integer-gmp [_63] trying: hashable-1.2.1.0:!bench [_64] trying: hashable-1.2.1.0:!test [_65] trying: hosc-0.14 (dependency of tidal-0.3.5) [_66] trying: hosc-0.14:!bench [_67] trying: hosc-0.14:!test [_68] trying: data-binary-ieee754-0.4.4 (dependency of hosc-0.14) [_69] trying: parsec-3.1.5 (dependency of tidal-0.3.5) [_70] trying: parsec-3.1.5:+base4 [_71] next goal: process (dependency of tidal-0.3.5) [_71] trying: process-1.2.0.0/installed-a5a... [_72] done Notice: installing into a sandbox located at /Users/adinapoli/programming/haskell/Tidal/.cabal-sandbox Ready to install SHA-1.6.4 cabal: internal error: scavenge_stack: weird activation record found on stack: 54 (GHC version 7.8.1 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 3861 abort cabal install -v3 -j }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 13:45:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 13:45:33 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.43f03b23c3b82b6c3801f2e031ef0ec5@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Comment (by slyfox): http://code.haskell.org/~slyfox/ghc-7.9.20140412-lto.log.txt: > error: variable 'nocldstop' redeclared as function > warning: type of 'stg_MUT_ARR_PTRS_CLEAN_info' does not match original declaration [enabled by default] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 15:18:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 15:18:03 -0000 Subject: [GHC] #8991: HLint: Illegal instruction (core dumped) Message-ID: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> #8991: HLint: Illegal instruction (core dumped) ----------------------------------+------------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- After upgrading to 7.8.1 output of {{{hlint}}} is {{{Illegal instruction (core dumped)}}} on any file that I tested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 16:05:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 16:05:43 -0000 Subject: [GHC] #7068: Extensive Memory usage (regression) In-Reply-To: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> References: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> Message-ID: <063.a2152be6a33abafefb57dd9b404c65eb@haskell.org> #7068: Extensive Memory usage (regression) -------------------------------------------------+------------------------- Reporter: waldheinz | Owner: Type: bug | simonpj Priority: high | Status: new Component: Compiler | Milestone: 7.8.3 Resolution: | Version: 7.4.1 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by George): When I try to reproduce on ghc 7.8.1 and Vec-1.0.1 with pcapriotti's instructions above I get a compilation error: {{{ ghc -fforce-recomp --make -O1 Data/Vec/LinAlg.hs -fspec-constr [1 of 3] Compiling Data.Vec.Nat ( Data/Vec/Nat.hs, Data/Vec/Nat.o ) [2 of 3] Compiling Data.Vec.Base ( Data/Vec/Base.hs, Data/Vec/Base.o ) [3 of 3] Compiling Data.Vec.LinAlg ( Data/Vec/LinAlg.hs, Data/Vec/LinAlg.o ) Data/Vec/LinAlg.hs:241:10: Illegal instance declaration for ?SetDiagonal v m? The liberal coverage condition fails in class ?SetDiagonal? for functional dependency: ?m -> v? Reason: lhs type ?m? does not determine rhs type ?v? In the instance declaration for ?SetDiagonal v m? Data/Vec/LinAlg.hs:580:10: Illegal instance declaration for ?Pivot a (() :. v)? The liberal coverage condition fails in class ?Pivot? for functional dependency: ?m -> a? Reason: lhs type ?() :. v? does not determine rhs type ?a? In the instance declaration for ?Pivot a (() :. v)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 16:07:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 16:07:24 -0000 Subject: [GHC] #7068: Extensive Memory usage (regression) In-Reply-To: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> References: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> Message-ID: <063.9705cc51194b93256e09ac25209efea5@haskell.org> #7068: Extensive Memory usage (regression) -------------------------------------------------+------------------------- Reporter: waldheinz | Owner: Type: bug | simonpj Priority: high | Status: new Component: Compiler | Milestone: 7.8.3 Resolution: | Version: 7.4.1 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 George): * cc: george.colpitts@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 20:42:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 20:42:57 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> In-Reply-To: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> References: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> Message-ID: <062.2273d1cf48bce7046c6d77290b600dc0@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------------------------------+------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc2 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 ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 20:43:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 20:43:19 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.7999a66f7278df1f0bee2143391963b7@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Changes (by ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 12 21:21:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Apr 2014 21:21:20 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.a00a0728c75c4ad4a02da61b48ce9bd6@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): And the GC results: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- circsim -0.5% -0.0% -0.9% -0.9% +4.4% constraints -0.5% -0.0% -1.9% -2.0% +0.2% fibheaps -0.5% -0.0% -2.1% -2.1% 0.0% fulsom -0.5% -0.0% -2.6% -2.6% -6.4% gc_bench -0.5% -0.0% -6.8% -6.8% -11.6% happy -0.4% -0.0% -4.0% -4.0% 0.0% hash -0.5% -0.0% -5.4% -5.4% 0.0% lcss -0.5% -0.0% -7.2% -7.2% 0.0% mutstore1 -0.5% -0.0% -3.1% -3.1% +4.5% mutstore2 -0.5% -0.0% -1.9% -1.9% +0.8% power -0.5% -0.0% -4.7% -4.7% 0.0% spellcheck -0.4% -0.0% -1.0% -0.9% +1.5% -------------------------------------------------------------------------------- Min -0.5% -0.0% -7.2% -7.2% -11.6% Max -0.4% -0.0% -0.9% -0.9% +4.5% Geometric Mean -0.5% -0.0% -3.5% -3.5% -0.6% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 07:40:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 07:40:22 -0000 Subject: [GHC] #8991: HLint: Illegal instruction (core dumped) In-Reply-To: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> References: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> Message-ID: <061.b5c813b1546a611e351b6a563fe93fa3@haskell.org> #8991: HLint: Illegal instruction (core dumped) -------------------------------------+---------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 ezyang): Also being tracked here: https://github.com/ndmitchell/hlint/issues/39 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 07:57:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 07:57:15 -0000 Subject: [GHC] #8992: Instructions for using gdb with GHC on Windows Message-ID: <045.5da142d588020e3fc1397add8a636ef7@haskell.org> #8992: Instructions for using gdb with GHC on Windows ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- gdb remains a useful tool for debugging executables on Windows, but getting it setup can be tricky, since modern gdb requires Python, which means you will end up installing MSYS Python alongside native Python. Unfortunately, MSYS Python doesn't work with the test suite, so one is in the delicate situation where you want your path to have MSYS Python if you're running gdb, but Windows Python if you're running the test suite. While one can work around this with modest annoyance (the easiest thing I've found is to just uninstall gdb/python when I'm not using it), it would be better if we removed this friction in some way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 08:00:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 08:00:34 -0000 Subject: [GHC] #5082: Emit warnings when conflicting flags are supplied In-Reply-To: <045.d94b5a730c81b9ffc21042de2f389b20@haskell.org> References: <045.d94b5a730c81b9ffc21042de2f389b20@haskell.org> Message-ID: <060.63fe235a9458052790ecddfc6ad63833@haskell.org> #5082: Emit warnings when conflicting flags are supplied -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | 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 ezyang): * priority: normal => low * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 08:01:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 08:01:16 -0000 Subject: [GHC] #5364: Access RTS flag values from inside Haskell programs In-Reply-To: <045.dac6fe30423f96742744c66f751179f8@haskell.org> References: <045.dac6fe30423f96742744c66f751179f8@haskell.org> Message-ID: <060.c4925146a344752b74623ab4517f321c@haskell.org> #5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.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: hvr (added) * difficulty: => Unknown Old description: > Strictly speaking, it is already possible to do this since > includes/rts/Flags.h exports RtsFlags, which can be accessed with a mini > wrapper function. We should add this wrapper function so we can import > it, and then write code which reads out the contents of all the various > parameters so that users can introspect this at runtime. Maybe put them > in the GHC.RTS module. New description: Strictly speaking, it is already possible to do this since `includes/rts/Flags.h` exports `RtsFlags`, which can be accessed with a mini wrapper function. We should add this wrapper function so we can import it, and then write code which reads out the contents of all the various parameters so that users can introspect this at runtime. Maybe put them in the `GHC.RTS` module. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 08:09:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 08:09:55 -0000 Subject: [GHC] #8491: Make BlockAlloc.c comments slightly more accurate In-Reply-To: <045.5e14ff3a04e439f527241772d8ef521e@haskell.org> References: <045.5e14ff3a04e439f527241772d8ef521e@haskell.org> Message-ID: <060.c223683f2559f17c3a78d86b258617d4@haskell.org> #8491: Make BlockAlloc.c comments slightly more accurate -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: patch Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Edward Z. Yang ): In [changeset:"7fa0b43593644fba8a3a60e5503a55268578d3c0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7fa0b43593644fba8a3a60e5503a55268578d3c0" Make BlockAlloc.c comment slightly more accurate (fixes #8491) Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 08:10:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 08:10:23 -0000 Subject: [GHC] #8491: Make BlockAlloc.c comments slightly more accurate In-Reply-To: <045.5e14ff3a04e439f527241772d8ef521e@haskell.org> References: <045.5e14ff3a04e439f527241772d8ef521e@haskell.org> Message-ID: <060.8c74c062deb6b860aeabeb466e41509d@haskell.org> #8491: Make BlockAlloc.c comments slightly more accurate -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: patch 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: new => closed * resolution: => fixed Comment: I went ahead and just pushed this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 08:59:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 08:59:16 -0000 Subject: [GHC] #8918: Network package doesn't load under GHC 7.8 RC on windows (?) In-Reply-To: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> References: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> Message-ID: <062.f7527d74a61ef310c0b561636f13f725@haskell.org> #8918: Network package doesn't load under GHC 7.8 RC on windows (?) --------------------------------------+---------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+---------------------------------- Comment (by awson): I think it's better to fix 'network' package. I've commented on this [https://github.com/haskell/network/issues/129#issuecomment-40302626 there]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 11:00:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 11:00:11 -0000 Subject: [GHC] #2123: implement waitForProcess using signals In-Reply-To: <047.96e17276f11f467a9162fc8e32a52352@haskell.org> References: <047.96e17276f11f467a9162fc8e32a52352@haskell.org> Message-ID: <062.e5c6b5cd472b8a88338ec3ac364d3c93@haskell.org> #2123: implement waitForProcess using signals -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: | Version: 6.8.2 libraries/process | Keywords: Resolution: | 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: -------------------------------------+------------------------------------- Changes (by redneb): * cc: redneb@? (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 11:04:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 11:04:53 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" In-Reply-To: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> References: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> Message-ID: <063.b9adabbb2d1110647c2926666b83ebf1@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by adinapoli): Interestingly enough, now I can't reproduce it anymore with 7.8.2. Keep you posted. Alfredo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 17:18:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 17:18:32 -0000 Subject: [GHC] #8918: Network package doesn't load under GHC 7.8 RC on windows (?) In-Reply-To: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> References: <047.1e9ba761fa9dc023d8755ecfd2935d3e@haskell.org> Message-ID: <062.b8ba4bb3053fce826f7f87f630463d9a@haskell.org> #8918: Network package doesn't load under GHC 7.8 RC on windows (?) --------------------------------------+---------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+---------------------------------- Comment (by dmcclean): Thanks for your help awson! This one was way out of my league. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 17:40:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 17:40:55 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC Message-ID: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> #8993: Fold NullaryTypeClasses into MPTC ------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- NullaryTypeClasses are an instance of MultiParamTypeClasses, so make it so. Suggested by Austin [http://www.reddit.com/r/haskell/comments/22lw1b/ghc_781_released/cgoi79c on reddit] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 13 21:34:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Apr 2014 21:34:56 -0000 Subject: [GHC] #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' In-Reply-To: <045.77f902a9eb98f7595f4855a4413508ee@haskell.org> References: <045.77f902a9eb98f7595f4855a4413508ee@haskell.org> Message-ID: <060.61ef9488df4e3b8a697f7c2654356980@haskell.org> #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' ----------------------------+---------------------------------------------- Reporter: songpp | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown PEi386 Operating System: Windows | Architecture: x86 Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: 3658 Test Case: | Related Tickets: #2487, #7103, #7889 Blocking: 8530 | ----------------------------+---------------------------------------------- Comment (by ezyang): 3noch: The fix for drectve should have made it into GHC 7.8.2. This bug is still open because we ostensibly want to relax the Windows linker's object checks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 05:53:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 05:53:19 -0000 Subject: [GHC] #8994: type checker could not deduce ambiguous instances Message-ID: <044.4073f3f8906b522824892c5e72c9cf07@haskell.org> #8994: type checker could not deduce ambiguous instances ------------------------------------+------------------------------------- Reporter: divip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC halts with a type error on the following program. If I comment out a seemingly unrelated part, it compiles though. Tested with GHC 7.8.2 {{{#!haskell {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} class (F a ~ Int) => -- if this line is commented out, the program compiles C a where type F a f :: b -> a run :: (forall a. C a => a) -> () run _ = () x = run (f 0) -- type error: Could not deduce (Num b0) arising from the literal ?0? from the context (C a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 06:07:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 06:07:29 -0000 Subject: [GHC] #8994: type checker could not deduce ambiguous instances In-Reply-To: <044.4073f3f8906b522824892c5e72c9cf07@haskell.org> References: <044.4073f3f8906b522824892c5e72c9cf07@haskell.org> Message-ID: <059.116a87e5e7466be8ec390380105ba770@haskell.org> #8994: type checker could not deduce ambiguous instances -------------------------------------+------------------------------------ Reporter: divip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by divip): GHC 7.6.3 compiles is. GHC 7.8.1 does not compile it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 07:32:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 07:32:00 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.ec31de1a476d14899237c1a0155050a1@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): Wow, I'm amazed you managed to get binary sizes to be smaller than before. So the only concerns now are those few strange looking results: cryptarithm, circsim, and I notice that spellcheck is not as good as before (runtime -6.4% before, -1.0% now). Also do you have any idea what is driving the increase in total memory (+100% for cryptarithm, +21% for circsim)? If startup time has increased, it would be a good idea to check on the startup time of GHC itself again, to give us an idea of the impact for a large program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 08:13:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 08:13:27 -0000 Subject: [GHC] #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) In-Reply-To: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> References: <045.abd2027873a2b9d9a2bc9aa2b4b749ea@haskell.org> Message-ID: <060.75cfc5c6f42744989f4421e235ca8d6a@haskell.org> #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Yes, I expect that we are reading the old interface file even if `-fforce- recomp` is on. It's a bit of a corner case, but I'd be happy to see it fixed if someone would like to construct a patch to stop that happening, and it's not too painful in code terms. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 08:15:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 08:15:29 -0000 Subject: [GHC] #8978: Type synonyms in class associated types behave strangely In-Reply-To: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> References: <047.a01c7e6628a96ca06391f160d3e4ac2e@haskell.org> Message-ID: <062.bffae93359823a2a04f6184a0b1b3c26@haskell.org> #8978: Type synonyms in class associated types behave strangely -------------------------------------------------+------------------------- Reporter: joelteon | Owner: Type: bug | Status: Priority: highest | closed Component: Compiler | Milestone: 7.8.2 Resolution: fixed | Version: 7.8.1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: indexed- | Unknown/Multiple types/should_compile/T8978 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T8978 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 09:31:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 09:31:34 -0000 Subject: [GHC] #8994: type checker could not deduce ambiguous instances In-Reply-To: <044.4073f3f8906b522824892c5e72c9cf07@haskell.org> References: <044.4073f3f8906b522824892c5e72c9cf07@haskell.org> Message-ID: <059.c8eead4cf91b46d1f059b71126061f6c@haskell.org> #8994: type checker could not deduce ambiguous instances -------------------------------------+------------------------------------ Reporter: divip | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: The reason this works in 7.6.3 is because GHC defaults the ambiguous type variable 'b', which arises from the call to `f` in `run (f 0)`. It sets `b := Integer`, and all is well. But 7.8 is more cautious about defaulting. Consider: {{{ class (c ~ Int) => C a c where type F a f :: b -> a run :: (forall a c. C a c => a) -> () }}} In this form there is another way to make the program typecheck, by setting `b := c`. So GHC's defaulting rule (which is necessarily ad-hoc, and always was), is a bit more conservative in 7.8, and declines to set `b := Integer` in case you really intended `b := c`. So you need a type signature. This would not be a hard design choice to liberalise. But I erred on the side of being conservative. Generally speaking it's better not to rely on defaulting, anyway. Just use that type signature! I'll close as invalid, but I'm open to user pressure! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 09:48:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 09:48:49 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.254df48171615e641afdd25e63db538e@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): My idea was to make `pprIfaceDecl` behave like `ppr_ty_thing`. The former is used only when displaying the contents of interface files, so it's ok for it to change a bit, particularly if the change is for the better. I think there will be bumps in the road, but we'll find them. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 10:26:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 10:26:08 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception In-Reply-To: <044.4c21331b0c5897214741257d5027da6d@haskell.org> References: <044.4c21331b0c5897214741257d5027da6d@haskell.org> Message-ID: <059.d1fd742f43f9f57011c76767e7e57d6c@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 simonpj): I have not thought about this deeply, but wouldn't something very similar happen with your change? The program will still crash, won't it? Would you like to give a test case? In any case, you are right that if you are going to do this at all, then something deepseq-like would be more thorough. By all means send a patch (with comments to explain). Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 11:54:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 11:54:34 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception In-Reply-To: <044.4c21331b0c5897214741257d5027da6d@haskell.org> References: <044.4c21331b0c5897214741257d5027da6d@haskell.org> Message-ID: <059.25ed6c01f9bd50995148e2c0d8eb463a@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 Yuras): Replying to [comment:2 simonpj]: > I have not thought about this deeply, but wouldn't something very similar happen with your change? The program will still crash, won't it? No, ghc is prepared for exceptions in splice, including nested exceptions. See Note [Exceptions in TH] and Note [Concealed TH exceptions] So with my change compilation gracefully fails with the next message: {{{ main.hs:1:1: Exception when trying to run compile-time code: Prelude.undefined Code: test }}} > > Would you like to give a test case? > > In any case, you are right that if you are going to do this at all, then something deepseq-like would be more thorough. > > By all means send a patch (with comments to explain). Thanks. Well, looks like it is not possible to use `deepseq` in `ghc`. Should I implement ad-hoc solution? Something like `deepseqString`? I don't believe it is the first time we need `deepseq`, so most likely it is already implemented somewhere. Thanks, Yuras -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 12:04:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 12:04:04 -0000 Subject: [GHC] #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism In-Reply-To: <047.369cd023f51a0cded951f791a8f64164@haskell.org> References: <047.369cd023f51a0cded951f791a8f64164@haskell.org> Message-ID: <062.b3f44eddbb51cee8c92f46b457db4d91@haskell.org> #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.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 Simon Peyton Jones ): In [changeset:"e7f0ae7ff4f2199abe42f20bac825a7802bff466/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e7f0ae7ff4f2199abe42f20bac825a7802bff466" Honour the untouchability of kind variables Trac #8985 showed up a major shortcoming in the kind unifier: it was ignoring untoucability. This has unpredictably-bad consequences; notably, the skolem-escape check can fail. There were two things wrong * TcRnMonad.isTouchableTcM was returning a constant value for kind variables (wrong), and even worse the constant was back-to-front (it was always False). * We weren't even calling isTouchableTcM in TcType.unifyKindX. I'm not sure how this ever worked. Merge to 7.8.3 in due course. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 12:06:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 12:06:42 -0000 Subject: [GHC] #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism In-Reply-To: <047.369cd023f51a0cded951f791a8f64164@haskell.org> References: <047.369cd023f51a0cded951f791a8f64164@haskell.org> Message-ID: <062.dbc2eb75e098b9b9af5a93f7740d2d70@haskell.org> #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.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 Simon Peyton Jones ): In [changeset:"ff9f9a7f2e227fcda7b8a2f52ec8be66de2e76cd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ff9f9a7f2e227fcda7b8a2f52ec8be66de2e76cd" Test Trac #8985 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 12:07:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 12:07:26 -0000 Subject: [GHC] #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism In-Reply-To: <047.369cd023f51a0cded951f791a8f64164@haskell.org> References: <047.369cd023f51a0cded951f791a8f64164@haskell.org> Message-ID: <062.64f6bf7d1d2e073c62b53d625a376aae@haskell.org> #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: polykinds/T8985 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * status: new => merge * testcase: => polykinds/T8985 Comment: Great catch, thank you. Merge to 7.8.3. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 12:09:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 12:09:14 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.6c39f54e05451ab544374fcd5a274218@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simons): * cc: simons (added) * version: 7.6.3 => 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 12:12:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 12:12:05 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception In-Reply-To: <044.4c21331b0c5897214741257d5027da6d@haskell.org> References: <044.4c21331b0c5897214741257d5027da6d@haskell.org> Message-ID: <059.4eb5c2899340dc8931fa2976f07ef0ee@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 simonpj): Yes, I see a `seqString` in `AsmCodeGen`, so perhaps pull it out into `Utils` and use it. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 12:31:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 12:31:30 -0000 Subject: [GHC] #8995: When generalising, use levels rather than global tyvars Message-ID: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> #8995: When generalising, use levels rather than global tyvars ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A long time ago Didier Remy described how to use 'ranks' or 'levels' to make the test "is this type variable free in the environment" when generalising a type. Oleg gives a [http://okmij.org/ftp/ML/generalization.html great explanation here]. GHC still uses the old "find the free type variables in the environment" method. But in fact GHC ''does'' maintain levels, just as Didier explains. The level is called `Untouchables` and is used to make sure we don't infer non-principal types for things involving GADTs. The same level stuff is used to prevent skolem-escape. Details with `Note [Untouchable type variables]` and `Note [Skolem escape prevention]` in `TcType`. So it ought to be straightforward to use the same levels for generalisation. I had a go, and came across the following tricky points: * We need to bump the level (`pushUntouchables`) when starting to typecheck a let RHS. Currently we don't. That will be a bit less efficient, because we'll end up deferring unification constraints that currently get solved immediately. * However the current set up is actually wrong. In particular, we generate a constraint where the implications do not have monotonically increasing level numbers (invariant `(ImplicInv)` in `TcType`). Try this program with `-ddump-tc-trace`. {{{ {-# LANGUAGE GADTs #-} module Bar where data T where MkT :: a -> (a->Int) -> T f x z = case x of MkT _ _ -> let g y = (y, [z,Nothing]) in (g True, g 'c') }}} I don't know how to make this bug cause an actual problem, but it's very unsettling. Bumping the level before doing the RHS would solve this. * Once we have bumped the level, we then have to do some more type- variable promotion, especially of type variables free in the finally- chosen type of the binder. This came out rather awkwardly in the code. * Because we now get more deferred equality constraints, there's a real risk that we'll end up quantifying over them. If we get, say `(gbl ~ Maybe lcl)`, where `gbl` is a type var free in the envt, we '''do not''' want to quantify over it! (It would be sound, but would lead to horrible types.) A long time ago Didier Remy described how to use 'ranks' or 'levels' to make the test "is this type variable free in the environment" when generalising a type. Oleg gives a [http://okmij.org/ftp/ML/generalization.html great explanation here]. GHC still uses the old "find the free type variables in the environment" method. But in fact GHC ''does'' maintain levels, just as Didier explains. The level is called `Untouchables` and is used to make sure we don't infer non-principal types for things involving GADTs. The same level stuff is used to prevent skolem-escape. Details with `Note [Untouchable type variables]` and `Note [Skolem escape prevention]` in `TcType`. So it ought to be straightforward to use the same levels for generalisation. I had a go, and came across the following tricky points: * We need to bump the level (`pushUntouchables`) when starting to typecheck a let RHS. Currently we don't. That will be a bit less efficient, because we'll end up deferring unification constraints that currently get solved immediately. * However the current set up is actually wrong. In particular, we generate a constraint where the implications do not have monotonically increasing level numbers (invariant `(ImplicInv)` in `TcType`). Try this program with `-ddump-tc-trace`. {{{ {-# LANGUAGE ExistentialQuantification #-} module Bar where data T = forall a. MkT a f x z = case x of MkT y -> let g y = [y,Nothing] in g True }}} Look for the `reportUnsolved` trace and you'll nested implications, both with level 1. I don't know how to make this bug cause an actual problem, but it's very unsettling. Bumping the level before doing the RHS would solve this. * Once we have bumped the level, we then have to do some more type- variable promotion, especially of type variables free in the finally- chosen type of the binder. This came out rather awkwardly in the code. * Because we now get more deferred equality constraints, there's a real risk that we'll end up quantifying over them. If we get, say `(gbl ~ Maybe lcl)`, where `gbl` is a type var free in the envt, we '''do not''' want to quantify over it! (It would be sound, but would lead to horrible types.) Rather we want to promote `lcl`, and not quantify. Currently we don't get many deferred equality constraints, becuase they all get done "on the fly". But if we do get one, we do quantify over it, which yields a rather stupid type. Try this: {{{ {-# LANGUAGE ExistentialQuantification #-} module Bar where data T = forall a. MkT a f x z = case x of MkT _ -> let g y = [z,Nothing] in (g True, g 'c') }}} We get this `g :: forall t a2. Maybe a ~ Maybe a2 => t -> [Maybe a2]`, where `x::a` is in the envt. Not very clever! This only shows up with existentials and In general I think we want to find all the type variables reachable by equality constraints from the environment, and not quantify over them. * We also use the type environment `getGlobalTyVars` in ''kind'' generalisation, and kind inference currently does not use the untoucahble story. Adapting it to use levels might be tricky because we currently assume we solve all kind equality constraints on-the-fly, and don't gather any deferreed constraints. Maybe it's easy, but needs thought. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 12:36:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 12:36:23 -0000 Subject: [GHC] #8995: When generalising, use levels rather than global tyvars In-Reply-To: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> References: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> Message-ID: <061.13c84f91c5faa0314b2dcac519281086@haskell.org> #8995: When generalising, use levels rather than global tyvars -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I've pushed my work-in-progress to branch `wip/T8995-level- generalisation`. Validate says this {{{ Unexpected failures: callarity/should_run StrictLet [exit code non-0] (normal) codeGen/should_run cgrun010 [exit code non-0] (normal) ghci.debugger/scripts break026 [bad stdout] (ghci) ghci.debugger/scripts print020 [bad stderr] (ghci) ghci/scripts ghci046 [bad stderr] (ghci) perf/haddock haddock.base [stat not good enough] (normal) polykinds T6068 [bad stderr] (ghci) }}} Pretty good really. A couple of these are Lint failures, though. The big reason I can't now get rid of `getGlobalTyVars` is the kind- generalisation point. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 12:56:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 12:56:29 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.d716072f50856a58f600cece9cf10b9e@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek 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 simonpj): I suppose that `tcPolyInfer` could check the returned `theta`, and ensure that it satisfies the rules for inflexible contexts, unless `FlexibleContexts` is enabled? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 13:00:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 13:00:33 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.3a0ad90c6896e324bfc1ae7893c15a75@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek 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 jstolarek): Ok, I'll try that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 13:37:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 13:37:05 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.fe0c1af3a9fce49e11c7885c96028e32@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): The same applies to `terminfo-0.4.0.0` and `haskeline-0.7.1.2` which have only the DSOs installed (and no interface files). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 14:47:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 14:47:16 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.37faccc2279ce2f983d9b059c74c6dcd@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): I think this will be enough: {{{ (x:+0)**(y:+0) = (x ** y) :+ 0 x ** y = exp (log x * y) }}} Testing: {{{ Prelude Data.Complex> 0**0 :: Complex Double 1.0 :+ 0.0 Prelude Data.Complex> 0**2 :: Complex Double 0.0 :+ 0.0 Prelude Data.Complex> 0**(-2) :: Complex Double Infinity :+ 0.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 15:04:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 15:04:29 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.24fcc882c66e9749eaa4b6a834960583@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): I have attached a working patch so we can discuss it. This solves the problem reported in the ticket but adds a couple of new ones that I'll hopefully solve as I get a better understanding of the codebase: 1. Bangs are not printed properly, specifically {-# UNPACK #-} pragmas 2. I don't really know how to get the family name for associated data families, right now instances are printed with the OccName as R:FamilyName Type Also, what should we do about RecursiveFlags, Promotable and Associated CTypes info ? right now these are not printed in order to conform to the current :info format. I have not added test cases or modified the old ones to conform to the new ppr format yer, I will add them when the ticket reaches the final form. Andrei -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 15:23:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 15:23:51 -0000 Subject: [GHC] #8991: HLint: Illegal instruction (core dumped) In-Reply-To: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> References: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> Message-ID: <061.eb34b9fc75090d6fc9b15b4e1057bbea@haskell.org> #8991: HLint: Illegal instruction (core dumped) -------------------------------------+---------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: -------------------------------------+---------------------------------- Changes (by tensor5): * version: 7.8.1 => 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 15:26:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 15:26:50 -0000 Subject: [GHC] #8991: HLint: Illegal instruction (core dumped) In-Reply-To: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> References: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> Message-ID: <061.d6b6880b889a0214dea2074d48a429a4@haskell.org> #8991: HLint: Illegal instruction (core dumped) -------------------------+------------------------------------------------- Reporter: | Owner: tensor5 | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Keywords: Component: | Architecture: x86_64 (amd64) Compiler | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: https://github.com/haskell- Unknown/Multiple | suite/haskell-src-exts/issues/96 Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Changes (by tensor5): * related: => https://github.com/haskell-suite/haskell-src-exts/issues/96 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 15:34:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 15:34:50 -0000 Subject: [GHC] #8991: HLint: Illegal instruction (core dumped) In-Reply-To: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> References: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> Message-ID: <061.635371d41d09661b1efcab099521498b@haskell.org> #8991: HLint: Illegal instruction (core dumped) -------------------------+------------------------------------------------- Reporter: | Owner: tensor5 | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Keywords: Component: | Architecture: x86_64 (amd64) Compiler | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: https://github.com/haskell- Unknown/Multiple | suite/haskell-src-exts/issues/96 Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by tensor5): As reported [https://github.com/haskell-suite/haskell-src-exts/issues/96 here], the same bug shows up in ghci in a simpler case: {{{ Prelude> :m Language.Haskell.Exts Prelude Language.Haskell.Exts> parseFileContents "main = putStrLn \"Hello World\"" Loading package array-0.5.0.0 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package old-time-1.1.0.2 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package polyparse-1.9 ... linking ... done. Loading package cpphs-1.18.4 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package haskell-src-exts-1.14.0.1 ... linking ... done. Illegal instruction (core dumped) }}} This bug only shows up in both my two AMD Athlon II X2 computers, but not on my Intel one, and it didn't show up with GHC 7.6.3. All three use Arch Linux x86_64 and GHC 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 16:58:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 16:58:31 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception In-Reply-To: <044.4c21331b0c5897214741257d5027da6d@haskell.org> References: <044.4c21331b0c5897214741257d5027da6d@haskell.org> Message-ID: <059.b8c136bc409c802987f919b207f7900e@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 Yuras): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 20:02:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 20:02:44 -0000 Subject: [GHC] #8996: mark more things as const in C codegen Message-ID: <045.8247ddb295df41a75076302911e81bc2@haskell.org> #8996: mark more things as const in C codegen -------------------------------------------+------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.2 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: -------------------------------------------+------------------------------- Recently i've tried to build ghc-7.8.2 on ia64 and it overflows so called "short data" section. (it's where global 'static' variables live). I've looked at low-hanging fruits of squashing such global "variables". One source of them seems to be a string literal. Consider one-line module: {{{ module B (v) where v = "hello" }}} in '''-fvia-C''' (or unreg) mode it generates code like {{{ static char gibberish_str[] = "hello"; }}} It uselessly eats data section. The patch switches generator to emit: {{{ static const char gibberish_str[] = "hello"; }}} Some notes: 1. as far as I see native codegens already put ot to .rodata, thus it should be safe. 2. I likely didn't cover more cases, like - RelocatableReadOnlyData - and mysterious '''pprTop (CmmData _section (Statics lbl [CmmUninitialised size]))''' Size of unreg-stage2 on amd64 before and after the patch: {{{ $ size inplace/lib/bin/ghc-stage2 (unpatched) text data bss dec hex filename 81986382 20776344 44096 102806822 620b526 inplace/lib/bin/ghc-stage2 $ size inplace/lib/bin/ghc-stage2 (patched) text data bss dec hex filename 83648494 19062936 44096 102755526 61fecc6 inplace/lib/bin/ghc-stage2 }}} Text section increased for 1.6MBs (consts moved here, likely .rodata actually), data section decreased for 1.7MBs. I think with minor fiddling with linker flags we can merge equal constants later on. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 21:16:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 21:16:17 -0000 Subject: [GHC] #8994: type checker could not deduce ambiguous instances In-Reply-To: <044.4073f3f8906b522824892c5e72c9cf07@haskell.org> References: <044.4073f3f8906b522824892c5e72c9cf07@haskell.org> Message-ID: <059.b0e4ab27debd4c127a235441f7e99869@haskell.org> #8994: type checker could not deduce ambiguous instances -------------------------------------+------------------------------------ Reporter: divip | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by divip): Thanks for the explanation. About my user experience: The example code was extracted from a bigger program. I did incremental refactoring steps on my program. In one step I introduced a new associated type which was independent of the rest of the program (like `type F a` above which should not interfere with defaulting), and my program stopped to compile. So I was almost sure this is a compiler bug. Improving on this behaviour is not very important for me, it was just unexpected during programming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 21:19:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 21:19:00 -0000 Subject: [GHC] #8994: type checker could not deduce ambiguous instances In-Reply-To: <044.4073f3f8906b522824892c5e72c9cf07@haskell.org> References: <044.4073f3f8906b522824892c5e72c9cf07@haskell.org> Message-ID: <059.e6b3ff83a39027754aef0ea719331421@haskell.org> #8994: type checker could not deduce ambiguous instances -------------------------------------+------------------------------------ Reporter: divip | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by divip): Thanks, wrote a reply below before I noticed there is a `reply` button. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 21:25:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 21:25:32 -0000 Subject: [GHC] #8996: mark more things as const in C codegen In-Reply-To: <045.8247ddb295df41a75076302911e81bc2@haskell.org> References: <045.8247ddb295df41a75076302911e81bc2@haskell.org> Message-ID: <060.79c238ca2ebec637e63e8f5ba9c50e7c@haskell.org> #8996: mark more things as const in C codegen -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ezyang): I think the intent is good. However, I'd probably go about doing it slightly differently: we want this to apply to all read-only data (so `ReadOnlyData`, `RelocatableReadOnlyData` and `ReadOnlyData16`), so it sounds like what you should do is go through all the PprC branches looking for places where a 'const' could be inserted, and then check if the relevant section is readonly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 14 21:49:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Apr 2014 21:49:32 -0000 Subject: [GHC] #8996: mark more things as const in C codegen In-Reply-To: <045.8247ddb295df41a75076302911e81bc2@haskell.org> References: <045.8247ddb295df41a75076302911e81bc2@haskell.org> Message-ID: <060.f7257ff0fc88d46b8ac9fff360e4124c@haskell.org> #8996: mark more things as const in C codegen -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: None/Unknown | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by slyfox): I think something, like use cases of {{{ pprLocalness :: CLabel -> SDoc pprLocalness lbl | not $ externallyVisibleCLabel lbl = ptext (sLit "static ") | otherwise = empty }}} might be very close to 'const' case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 03:48:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 03:48:32 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.19fa8eff7f55ea5d2c09b9e8ba88b2a5@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by td123): Just encountered this issue on archlinux since mtl was getting installed but it's dep on transformers wasn't. My journey ended at this ticket. Here is a full list of packages that are used internally, but contain files when you make install: haskell-haskeline=0.7.1.2 haskell-hoopl=3.9.0.0 haskell-terminfo=0.4.0.0 haskell-transformers=0.3.0.0 haskell-xhtml=3000.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 05:11:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 05:11:49 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.b9625beb46f56bfca24f2f8333580d6c@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by td123): Investigating this further, it looks like this isn't a case of files getting accidentally included. I found the following comment in ghc.mk # If we have built the programs with dynamic libraries, then # ghc will be dynamically linked against haskeline.so etc, so # we need the dynamic libraries of everything down to here Which looks like it includes these libs if DYNAMIC_GHC_PROGRAMS is set to "YES" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 06:26:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 06:26:35 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.e23ed7335b6653a4793ea69ecfb33dd1@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by felixonmars): * cc: felixonmars@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 06:44:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 06:44:52 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.a1bb208fdffd8485d6e8ef0e91d679d1@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:4 td123]: > Just encountered this issue on archlinux since mtl was getting installed but it's dep on transformers wasn't. My journey ended at this ticket. > > Here is a full list of packages that are used internally, but contain files when you make install: > > haskell-haskeline=0.7.1.2 > haskell-hoopl=3.9.0.0 > haskell-terminfo=0.4.0.0 > haskell-transformers=0.3.0.0 > haskell-xhtml=3000.2.1 Strange, `transformers` and `hoopl` shouldn't be in that list (i.e. as mentioned earlier in this ticket, only `haskeline`,`terminfo`, and `xhtml` are problematic), as those are actually needed by the `ghc` package (and they will show up in `ghc-pkg list` for a properly performed GHC installation) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 07:03:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 07:03:06 -0000 Subject: [GHC] #8024: Dynamic linking not working on PowerPC Linux. In-Reply-To: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> References: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> Message-ID: <059.94f5149ed41bab15b9dff29d4dbcab36@haskell.org> #8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by PHO): * cc: pho@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 08:54:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 08:54:09 -0000 Subject: [GHC] #8997: Warn about unused parameters in recursive definitions Message-ID: <046.1e4a4d8e7db6c38fc9fb975f767e899e@haskell.org> #8997: Warn about unused parameters in recursive definitions ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I?m correcting student?s exams right now; a good source of bad programs :-) Consider this program: {{{ foo _ y [] = y foo z y (_:xs) = foo z y xs }}} It would be nice if GHC would warn that the first parameter of `foo` is not used. IIRC GHC warns about unused constructors even when they occur on RHSs. If `foo` is passed to some higher order function that expects a particular type, removing the parameter would require a wrapper for there, or at least an anonymous lambda... but it?s probably still worth notifying the programmer, as more likely there is a bug or misunderstanding in such code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 10:33:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 10:33:17 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception In-Reply-To: <044.4c21331b0c5897214741257d5027da6d@haskell.org> References: <044.4c21331b0c5897214741257d5027da6d@haskell.org> Message-ID: <059.ef06eb51f9484e7ffb3c4b4271f006f1@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 simonpj): Looks great. But where is `Note [Exceptions in TH]`? If you could just add that, it'd be great. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 11:42:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 11:42:05 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception In-Reply-To: <044.4c21331b0c5897214741257d5027da6d@haskell.org> References: <044.4c21331b0c5897214741257d5027da6d@haskell.org> Message-ID: <059.40629395c137226d6b0fcb068857525c@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 Yuras): Replying to [comment:6 simonpj]: > Looks great. But where is `Note [Exceptions in TH]`? If you could just add that, it'd be great. It is already here, 50 lines above. It perfectly explains how TH handles exceptions, I have little to nothing to add. I don't think we need special Note about `qReport`, but I added few lines to an existent Note. But I'm not sure it worth adding, the notes are pretty clear already. Let me know if prefer one patch, combining all the 3 attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 12:03:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 12:03:46 -0000 Subject: [GHC] #7066: isInstance does not work for compound types In-Reply-To: <044.f26fdb7a0d5666f6e8ecfbb0861afaff@haskell.org> References: <044.f26fdb7a0d5666f6e8ecfbb0861afaff@haskell.org> Message-ID: <059.80bf3f22aafcd1c2c7afa0eeb01cb364@haskell.org> #7066: isInstance does not work for compound types -------------------------------------+------------------------------------ Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Template Haskell | 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 simonpj): Hmm: * Are you making the case for an actual change in the behaviour of the current TH operations? The current `reifyInstances` is deliberately primitive (a one-level lookup) so that other stuff can be built on top. Or are you asking for some new functions in the `Quasi` monad; or new functions in the `template-haskell` library? * It would help a lot to be clear precisely what the behaviour is supposed to be when the types concerned contain type variables. Currently `reifyInstances` returns all the instance whose heads unify with the specified constraint. I've looked at your code and it's not clear to me exactly what it does. Could you write a specification? * I think it's arguable that what you ''really'' want is something like {{{ isInstance :: Cxt -> Name -> [Type] -> Q Bool }}} return `True` if the constraint `(C tys)` is provable from the specifed context. For example, you could ask, say `isIntance [Show a, Num a] Foo [Maybe a]`, to ask whether you can prove `(Foo (Maybe a))` from `(Show a, Num a)`. For ground types you could give the empty `Cxt`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 13:12:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 13:12:04 -0000 Subject: [GHC] #8943: Add System.Process.createPipe In-Reply-To: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> References: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> Message-ID: <059.cedb432a95756faca9a63dee998c8c27@haskell.org> #8943: Add System.Process.createPipe --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/process | 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 think this issue is stalled since someone on Windows can figure out the issue simonmar mentioned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 14:00:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 14:00:07 -0000 Subject: [GHC] #7066: isInstance does not work for compound types In-Reply-To: <044.f26fdb7a0d5666f6e8ecfbb0861afaff@haskell.org> References: <044.f26fdb7a0d5666f6e8ecfbb0861afaff@haskell.org> Message-ID: <059.3c3e4615364a6c455e7ad45fc39903d1@haskell.org> #7066: isInstance does not work for compound types -------------------------------------+------------------------------------ Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Template Haskell | 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 mojojojo): > Are you making the case for an actual change in the behaviour of the current TH operations? The current reifyInstances is deliberately primitive (a one-level lookup) so that other stuff can be built on top. Or are you asking for some new functions in the Quasi monad; or new functions in the template-haskell library? Well. I consider the current behaviour of `reifyInstances` counterintuitive, to say at very least. It took me quite some time of debugging the library I was developing at the time, before I narrowed the issue I was experiencing down to the unexpected behaviour of `reifyInstances`. Only then did I get to googling and finally here to find out that it's actually an intended behaviour, though misleadingly documented. Let's consider the use cases for that function. All I can imagine is finding the instances, which then can be relied on as applicable to the tested types. I can imagine no scenario, in which one would want to get instances, which the typechecker would deny. Can you imagine any examples of such a case? Considering the above, I can only see the current behaviour of that function as a bug. However I am not strongly opinionated about changing that, especially since I've already published a solution. The documentation however definitely should be updated to make the behaviour of this function clear. > It would help a lot to be clear precisely what the behaviour is supposed to be when the types concerned contain type variables. Currently reifyInstances returns all the instance whose heads unify with the specified constraint. I've looked at your code and it's not clear to me exactly what it does. Could you write a specification? I've [https://github.com/nikita-volkov/th-instance- reification/blob/master/src/THInstanceReification.hs#L36-L87 updated the code] by covering it with extensive comments. [https://github.com/nikita- volkov/th-instance-reification/blob/master/src/HTFTestSuite.hs The test suite] should also be useful for clarifying the expected behaviour. > I think it's arguable that what you really want is something like > {{{isInstance :: Cxt -> Name -> [Type] -> Q Bool}}} > return True if the constraint (C tys) is provable from the specifed context. For example, you could ask, say isIntance [Show a, Num a] Foo [Maybe a], to ask whether you can prove (Foo (Maybe a)) from (Show a, Num a). For ground types you could give the empty Cxt. Yes, this looks like it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 16:19:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 16:19:30 -0000 Subject: [GHC] #8998: GHCi infers types that are too restrictive Message-ID: <054.b0e92d27a3a0d4efe7919d0586975c60@haskell.org> #8998: GHCi infers types that are too restrictive ------------------------------------+------------------------------------- Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 the following is loaded into ghci: {{{ import Data.Function test1 = (/) `on` fromInteger test2 = (/) `on` fromInteger asd = test2 1 2 :: Rational test3 = fromInteger }}} I get the following types: {{{ (test1,test2,test3) :: (Integer -> Integer -> Double, Integer -> Integer -> GHC.Real.Ratio Integer, Integer -> Integer) }}} The correct output should be: {{{ (test1,test2,test3) :: (Fractional c, Fractional c1, Num a) => (Integer -> Integer -> c, Integer -> Integer -> c1, Integer -> a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 16:26:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 16:26:33 -0000 Subject: [GHC] #8998: GHCi infers types that are too restrictive In-Reply-To: <054.b0e92d27a3a0d4efe7919d0586975c60@haskell.org> References: <054.b0e92d27a3a0d4efe7919d0586975c60@haskell.org> Message-ID: <069.18741b1d3c01a5c1d4e3b43889dd2696@haskell.org> #8998: GHCi infers types that are too restrictive -------------------------------------+------------------------------------ Reporter: j80JjBjVNRMajmA | 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 simonpj): Try with `-X NoMonomorphismRestriction`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 16:30:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 16:30:46 -0000 Subject: [GHC] #8998: GHCi infers types that are too restrictive In-Reply-To: <054.b0e92d27a3a0d4efe7919d0586975c60@haskell.org> References: <054.b0e92d27a3a0d4efe7919d0586975c60@haskell.org> Message-ID: <069.41dae9f4cf2bb923756e3a142c5ae66e@haskell.org> #8998: GHCi infers types that are too restrictive -------------------------------------+------------------------------------ Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 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 j80JjBjVNRMajmA): * status: new => closed * resolution: => invalid Comment: Ok. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 16:54:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 16:54:23 -0000 Subject: [GHC] #8999: Type synonym not normalized in instance head Message-ID: <044.56bdc9cc24a2916d017797ea5fb1cc5f@haskell.org> #8999: Type synonym not normalized in instance head ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE ConstraintKinds, KindSignatures #-} type Foo (m :: * -> *) = Monad m data T a = T (Maybe a) instance Foo T where return = T Nothing }}} this gives the bogus error {{{ T.hs:8:3: ?return? is not a (visible) method of class ?Foo? }}} incidentally, it works okay when giving no where clause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 17:58:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 17:58:13 -0000 Subject: [GHC] #8999: Type synonym not normalized in instance head In-Reply-To: <044.56bdc9cc24a2916d017797ea5fb1cc5f@haskell.org> References: <044.56bdc9cc24a2916d017797ea5fb1cc5f@haskell.org> Message-ID: <059.5ef9a4bc7ffb71ee4871adffccf960eb@haskell.org> #8999: Type synonym not normalized in instance head -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: See #7543. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 18:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 18:14:33 -0000 Subject: [GHC] #8999: Type synonym not normalized in instance head In-Reply-To: <044.56bdc9cc24a2916d017797ea5fb1cc5f@haskell.org> References: <044.56bdc9cc24a2916d017797ea5fb1cc5f@haskell.org> Message-ID: <059.b50eaa1524a267d2ce1deea746804b11@haskell.org> #8999: Type synonym not normalized in instance head -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): Ah, apologies! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 18:24:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 18:24:53 -0000 Subject: [GHC] #8115: GHC 64-bit Windows build failures with LLVM In-Reply-To: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> References: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> Message-ID: <061.d384da7f20aa0f7e6bc370ab1484652d@haskell.org> #8115: GHC 64-bit Windows build failures with LLVM ---------------------------------+------------------------------------ Reporter: schyler | Owner: Type: bug | Status: new Priority: highest | 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: ---------------------------------+------------------------------------ Comment (by awson): I think this ticket can be closed, because we have no this bug in 7.8+ (we have #7134 and #8974 though). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 20:04:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 20:04:24 -0000 Subject: [GHC] #7744: Can't install conduit via cabal-install In-Reply-To: <044.9ee481f0464202727ca68974cec184b9@haskell.org> References: <044.9ee481f0464202727ca68974cec184b9@haskell.org> Message-ID: <059.6228feadaaa8da3998aac567efef0773@haskell.org> #7744: Can't install conduit via cabal-install ---------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 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 yezariaely): * cc: rj@? (added) * resolution: worksforme => * status: closed => new * os: Linux => MacOS X * version: 7.6.2 => 7.6.3 Comment: It still crashes for me. Reason seems to be: {{{ Data/Conduit/Internal.hs:371:4: error: invalid preprocessing directive #-} ^ }}} Here the full log in details. Any ideas? {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 $ cabal --version cabal-install version 1.18.0.3 using version 1.18.1.3 of the Cabal library }}} {{{ $ cabal install conduit Resolving dependencies... Configuring conduit-1.1.0... Building conduit-1.1.0... Preprocessing library conduit-1.1.0... Data/Conduit/Internal.hs:101:47: warning: missing terminating ' character [-Winvalid-pp-token] -- * /i/ is the type of values for this @Pipe@'s input stream. ^ Data/Conduit/Internal.hs:103:47: warning: missing terminating ' character [-Winvalid-pp-token] -- * /o/ is the type of values for this @Pipe@'s output stream. ^ Data/Conduit/Internal.hs:171:64: warning: \u used with no following hex digits; treating as '\' followed by identifier [-Wunicode] local f (NeedInput p c) = NeedInput (\i -> local f (p i)) (\u -> local f (c u)) ^ Data/Conduit/Internal.hs:189:62: warning: \u used with no following hex digits; treating as '\' followed by identifier [-Wunicode] listen (NeedInput p c) = NeedInput (\i -> listen (p i)) (\u -> listen (c u)) ^ Data/Conduit/Internal.hs:194:26: warning: missing terminating ' character [-Winvalid-pp-token] return $ do (x,w') <- listen p ^ Data/Conduit/Internal.hs:195:46: warning: missing terminating ' character [-Winvalid-pp-token] return (x, w `mappend` w') ^ Data/Conduit/Internal.hs:199:58: warning: \u used with no following hex digits; treating as '\' followed by identifier [-Wunicode] pass (NeedInput p c) = NeedInput (\i -> pass (p i)) (\u -> pass (c u)) ^ Data/Conduit/Internal.hs:216:74: warning: \u used with no following hex digits; treating as '\' followed by identifier [-Wunicode] catchError (NeedInput p c) f = NeedInput (\i -> catchError (p i) f) (\u -> catchError (c u) f) ^ Data/Conduit/Internal.hs:334:50: warning: missing terminating ' character [-Winvalid-pp-token] awaitForever :: Monad m => (i -> Pipe l i o r m r') -> Pipe l i o r m r ^ Data/Conduit/Internal.hs:371:4: error: invalid preprocessing directive #-} ^ Data/Conduit/Internal.hs:576:13: warning: missing terminating ' character [-Winvalid-pp-token] pipe' <- mpipe ^ Data/Conduit/Internal.hs:577:18: warning: missing terminating ' character [-Winvalid-pp-token] case pipe' of ^ Data/Conduit/Internal.hs:579:29: warning: missing terminating ' character [-Winvalid-pp-token] _ -> return pipe' ^ Data/Conduit/Internal.hs:622:83: warning: missing terminating ' character [-Winvalid-pp-token] mapInput f f' (NeedInput p c) = NeedInput (mapInput f f' . p . f) (mapInput f f' . c) ^ Data/Conduit/Internal.hs:625:82: warning: missing terminating ' character [-Winvalid-pp-token] mapInput f f' (Leftover p i) = maybe id (flip Leftover) (f' i) $ mapInput f f' p ^ Data/Conduit/Internal.hs:702:35: warning: \u used with no following hex digits; treating as '\' followed by identifier [-Wunicode] loop = awaitE >>= either (\u -> return (u, r)) (\_ -> loop) ^ Data/Conduit/Internal.hs:723:14: warning: missing terminating ' character [-Winvalid-pp-token] let final' = do ^ Data/Conduit/Internal.hs:726:58: warning: missing terminating ' character [-Winvalid-pp-token] return (liftIO (I.writeIORef ref False) >> src, final') ^ Data/Conduit/Internal.hs:884:76: warning: \u used with no following hex digits; treating as '\' followed by identifier [-Wunicode] NeedInput px cx >< y at Done{} = NeedInput (\i -> px i >< y) (\u -> cx u >< y) ^ Data/Conduit/Internal.hs:885:76: warning: \u used with no following hex digits; treating as '\' followed by identifier [-Wunicode] x at Done{} >< NeedInput py cy = NeedInput (\i -> x >< py i) (\u -> x >< cy u) ^ Data/Conduit/Internal.hs:957:10: warning: \u used with no following hex digits; treating as '\' followed by identifier [-Wunicode] (\u -> go finalX finalY (cx u) (cy u)) ^ Data/Conduit/Internal.hs:960:10: warning: \u used with no following hex digits; treating as '\' followed by identifier [-Wunicode] (\u -> go finalX finalY (cx u) (Done y)) ^ Data/Conduit/Internal.hs:963:10: warning: \u used with no following hex digits; treating as '\' followed by identifier [-Wunicode] (\u -> go finalX finalY (Done x) (cy u)) ^ Data/Conduit/Internal.hs:1059:14: warning: missing terminating ' character [-Winvalid-pp-token] let final' = do ^ Data/Conduit/Internal.hs:1062:58: warning: missing terminating ' character [-Winvalid-pp-token] return (liftIO (I.writeIORef ref False) >> src, final') ^ 24 warnings and 1 error generated. Failed to install conduit-1.1.0 cabal: Error: some packages failed to install: conduit-1.1.0 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 20:16:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 20:16:15 -0000 Subject: [GHC] #7744: Can't install conduit via cabal-install In-Reply-To: <044.9ee481f0464202727ca68974cec184b9@haskell.org> References: <044.9ee481f0464202727ca68974cec184b9@haskell.org> Message-ID: <059.32385b3284fa346a20cc301c3c8ba0a7@haskell.org> #7744: Can't install conduit via cabal-install ---------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: invalid | 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 yezariaely): * status: new => closed * resolution: => invalid Comment: Just saw that this is of course not a ghc bug. Sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 20:19:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 20:19:23 -0000 Subject: [GHC] #8991: HLint: Illegal instruction (core dumped) In-Reply-To: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> References: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> Message-ID: <061.3311f0534a29e2c7d53e3e8745ccf2cd@haskell.org> #8991: HLint: Illegal instruction (core dumped) -------------------------+------------------------------------------------- Reporter: | Owner: tensor5 | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Keywords: Component: | Architecture: x86_64 (amd64) Compiler | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: https://github.com/haskell- Unknown/Multiple | suite/haskell-src-exts/issues/96 Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by tensor5): Solved after upgrading to haskell-src-exts-1.15.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 20:44:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 20:44:04 -0000 Subject: [GHC] #8995: When generalising, use levels rather than global tyvars In-Reply-To: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> References: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> Message-ID: <061.c1e19d94230b14d7b875567df85fc3f3@haskell.org> #8995: When generalising, use levels rather than global tyvars -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by remy): Hi Simon, Oleg pointed me to your implementation issue in case I could help... I do not understand all the details because I do not know the internals of GHC, but I do believe that you only need one notion of ranks. However, I am a bit confused by your description. First, because GHC does not generalizes unanotated local let-binding, then you should not have to play with ranks around (unnanotaed) let-bindings or perhaps the case you are describing is that of annotated local-let bindings. So below, I'll asume that you do generalize then as in ML, and I'll describe how ranks can work for ML (formally, you can see [1], which has later be generalized by typing constraints [2]). You say that you want to increase the rank on RHS of a Let-bindings, but I do not see why. Or is it a typo and you meant LHS? In ML, we increase the rank on LHS of a let-bindings, because this is the type that we will have to generalize. So when generalizing we just have to pick variables of higher-rank (i.e. those introduced during the type checking of the LHS that haven't be downgraded during resolution of the constraint). More precisely, "let x = a1 in a2" is typechecked at rank n as follows: 1) typecheck a1 at rank (n+1): this generates constraint C with fresh variables/nodes introduced at rank (n+1). 2) solve the fresh part of the constraint (that at rank n+1); this may downgrade some fresh nodes to rank n or lower. 3) generalize nodes that remain at rank (n+1); this returns a type scheme S. 4) typecheck a2 at rank n in the environment extended with x : S. In particular, I do not understand why you would increase the level when typechecking the RHS. You just return to the level n at which the whole let-biding is being typechecked. In step 2, variables may be downgraded to lower ranks in two cases: 1) when they have to be unified with a type of a lower rank (either one that has to be of a lower rank, e.g. a type variable introduced at a lower rank, 2) when they are equal to a term whose variables are all of lower rank. My understanding is that Step 2 is what you describe as one of the problem. Steps 1) and 2) can also be explained in term of typing constraints as presented in [2]. At generalization points it is useful to remove useless quantifications (which would be correct but unnecessarily copy too much of the type scheme). This is done by rule C-LetApp (p. 32) that transforms a constraints: let x : forall (Xs, Ys | C1) T in C2 into exists (Ys) let x : forall (Xs | C1) T in C2 provided "Ys" are disjoint from "ftv (C2)" and "exists (Xs) C1 _dertermines_ Ys". Here, turning "all (Ys)" into "exist (YS)" amounts to decreasing the rank of "Ys". The definition of "determines" is semantical at this point, but we later give syntactic sufficient conditions in the case of equality constraints (lemma 1.8.7 on page 82) which, as explained on p. 83, includes the two cases corresponding the ones above: 1) a variable X may be moved to Ys when it is dominated by a node of lower rank (a free variable exists (Xs) C1). 2) a variable X may be moved to Ys when all variables it dominates are already in Ys. So it does not harm at all to keep delayed constraints in type schemes, but 1) the generic part of the constraint should be simplified, so as to ensure that the (generic part of the) type scheme is solvable and 2) delayed constraints must be (carefully) taken into account at generalisation time to avoid generalizing too many type variables (those that are "determined" from the context) I hope I haven't completely misunderstood your problem... Didier [1] http://hal.inria.fr/docs/00/07/70/06/PS/RR-1766.ps) [2] ATTAPL, the essence of ML. (Page numbers refers to the online draft version http://cristal.inria.fr/attapl/preversion.ps.gz) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 22:01:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 22:01:07 -0000 Subject: [GHC] #8882: internal error (deriving generic / cyclical imports?) In-Reply-To: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> References: <044.1daca3870a219aee32c2f06e9482c6a5@haskell.org> Message-ID: <059.8eda507091bcafef48cb3a36c738be6b@haskell.org> #8882: internal error (deriving generic / cyclical imports?) -------------------------------+---------------------------------- Reporter: mf825 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: panic Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7878, 8374 -------------------------------+---------------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: Closing, as discussed above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 23:14:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 23:14:48 -0000 Subject: [GHC] #9000: Kind checking fails when using PolyKinds Message-ID: <056.beec0cddf4cb02b2cbcae89ea4adcd39@haskell.org> #9000: Kind checking fails when using PolyKinds -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Linux Keywords: | Type of failure: GHC rejects Architecture: x86_64 (amd64) | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- GHC HEAD and earlier versions are failing on the following program: {{{ {-# LANGUAGE PolyKinds #-} import GHC.Exts(Any) f = (undefined :: a -> m a) :: Any -> Any Any }}} {{{ ../tmp/test-polykinds.hs:3:6: Couldn't match kind ?k1? with ?*? ?k1? is a rigid type variable bound by an expression type signature: Any -> Any Any at ../tmp/test-polykinds.hs:3:5 Expected type: Any -> Any Any Actual type: Any -> m0 Any In the expression: (undefined :: a -> m a) :: Any -> Any Any In an equation for ?f?: f = (undefined :: a -> m a) :: Any -> Any Any }}} Rewriting the program as follows has compilation succeed. {{{ f = (undefined :: a -> m a) `asTypeOf` (undefined :: Any -> Any Any) }}} And removing the {{{PolyKinds}}} extension also has compilation succeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 15 23:30:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Apr 2014 23:30:39 -0000 Subject: [GHC] #9000: Kind checking fails when using PolyKinds In-Reply-To: <056.beec0cddf4cb02b2cbcae89ea4adcd39@haskell.org> References: <056.beec0cddf4cb02b2cbcae89ea4adcd39@haskell.org> Message-ID: <071.e171d82d25d9435c9244eae7684cb424@haskell.org> #9000: Kind checking fails when using PolyKinds ----------------------------------------------+---------------------------- Reporter: facundo.dominguez | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Resolution: | 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 facundo.dominguez): * cc: facundominguez@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 00:00:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 00:00:56 -0000 Subject: [GHC] #9000: Kind checking fails when using PolyKinds In-Reply-To: <056.beec0cddf4cb02b2cbcae89ea4adcd39@haskell.org> References: <056.beec0cddf4cb02b2cbcae89ea4adcd39@haskell.org> Message-ID: <071.8f5f3d0cf6866d7a00aa4fb8546bda25@haskell.org> #9000: Kind checking fails when using PolyKinds ----------------------------------------------+---------------------------- Reporter: facundo.dominguez | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 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 goldfire): * status: new => closed * resolution: => invalid Comment: This (admittedly bizarre) behavior is (arguably) correct. Let's look at the kinds of the different pieces. In the type `a -> m a`, the kinds are fixed. We must have `(a :: *)` and `(m :: * -> *)`. However, in the type `Any -> Any Any`, a kind variable comes in. Annotating each `Any`, we get `(Any :: *) -> (Any :: k1 -> *) (Any :: k1)`. Why are these different? Because the `a` is repeated in the first type, but every `Any` is independent in the second. In the failing version of the code, the outer type signature is more general than the inner one, which is no good. With `asTypeOf`, in contrast, GHC unifies the two types, and the kind variable `k1` is unified with `*`, yielding a successful compilation. Although it may seem strange that the `::` use case and the `asTypeOf` use case differ, consider `False :: a` and {{{False `asTypeOf` (undefined :: a)}}}. The first fails and the second succeeds. Because kinds are implicit by default, this sort of unexpected behavior comes up fairly often. My best suggestion is to use `-fprint-explicit- kinds` liberally to try to detect when this is happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 00:26:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 00:26:27 -0000 Subject: [GHC] #8943: Add System.Process.createPipe In-Reply-To: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> References: <044.78c29afcb2d7ba48a111dfadbe70b4a3@haskell.org> Message-ID: <059.a6a63590e498569d5fb9df031174929c@haskell.org> #8943: Add System.Process.createPipe --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/process | 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 refold): I'll look into it once I get some free time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 02:28:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 02:28:45 -0000 Subject: [GHC] #9000: Kind checking fails when using PolyKinds In-Reply-To: <056.beec0cddf4cb02b2cbcae89ea4adcd39@haskell.org> References: <056.beec0cddf4cb02b2cbcae89ea4adcd39@haskell.org> Message-ID: <071.2a6557adf895a7d038e170fc1f5d1fb3@haskell.org> #9000: Kind checking fails when using PolyKinds ----------------------------------------------+---------------------------- Reporter: facundo.dominguez | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 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: ----------------------------------------------+---------------------------- Comment (by facundo.dominguez): The option {{{-fprint-explicit-kinds}}} improves a lot the error message. Thanks for the good summary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 06:29:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 06:29:38 -0000 Subject: [GHC] #9001: unexpected runtime crash Message-ID: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> #9001: unexpected runtime crash ------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Apologies for the poor summary, I'm not sure how to be more descriptive. I don't see anything dodgy here. Compiling the attached program `ghc -O -dcore-lint Test.hs` and running it results in a runtime crash. Various incarnations of this code have resulted in Test: internal error: scavenge_one: strange object 0 Test: internal error: stg_ap_p_ret and core dumps with no further information. I've been able to reproduce this with ghc-7.8.2 and ghc-7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 08:40:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 08:40:35 -0000 Subject: [GHC] #8995: When generalising, use levels rather than global tyvars In-Reply-To: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> References: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> Message-ID: <061.d2ee865eba9a1a7e8b5090eb77c2e22d@haskell.org> #8995: When generalising, use levels rather than global tyvars -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Thanks Didier. First, two confusions: * I think of let-bindings of form `let x = in `. So when I say "RHS" I mean the bit that you called `a2` above. So I think we are in agreement here. * In principle GHC does not do local let-generalisation, as our papers advertise. But GHC must compile Haskell 98, so it must somehow support local let-generalisation. So in fact: * Local let-gen is enabled by `-XNoMonoLocalBinds` and disabled by `-XMonoLocalBinds`. * By default, we have `-XNoMonoLocalBinds`. * But with `-XGADTs` or `-XTypeFamilies` we also switch on `-XMonoLocalBinds`. * But that can again be overridden, so `-XGADTs -XNoMonoLocalBings` would attempt to generalise local let-bindings despite the problems with doing so. The other thing is that the "monomorphism restriction" can mean that even a top-level binding can have an environment with free type variables. `-XNoMonomorphismRestriction` switches this off. So this ticket is all about the "best-efforts" generalisation you get when you have `-XNoMonoLocalBinds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 09:11:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 09:11:21 -0000 Subject: [GHC] #9002: bus error on sparc in ffi call Message-ID: <046.0f1e0eef29c036a6cc921114c21e878a@haskell.org> #9002: bus error on sparc in ffi call ----------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: sparc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------- Trying to run the test-suite of tls-1.2.6 on sparc with GHC 7.6.3, I get {{{ Marshalling: Header: [OK, passed 100 tests] Handshake: [OK, passed 100 tests] Ciphers: Bulk: [OK, passed 100 tests] Handshakes: setup: [OK, passed 100 tests] Program received signal SIGBUS, Bus error. 0x003d8b9c in md5_do_chunk () (gdb) bt #0 0x003d8b9c in md5_do_chunk () #1 0x003d9980 in md5_update () #2 0x003d1fe0 in saqF_ret () #3 0x00da1db8 in StgRun () #4 0x00d9f5cc in scheduleWaitThread () #5 0x00d9c6e4 in real_main () #6 0x00d9c838 in hs_main () #7 0x0003b624 in main () }}} Any sparc interested people here that can try to reproduce and fix this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 09:25:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 09:25:16 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) Message-ID: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------------------+------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- A patch in GHC-7.7 modified the "thread stop status" encoding, so the current ghc-events (version 0.4.2.0 from 2012) produces wrong stop reasons when reading an eventlog written by GHC-7.8.2. The GHC patch is http://git.haskell.org/ghc.git/commit/70e20631742e516c6a11c3c112fbd5b4a08c15ac The MVarRead block reason was added in the middle, shifting all following block reason codes one up. The error can be observed when a thread blocks on a black hole during a program run. Attached is a small test program which produces this situation, and two event logs for the same program run with the same arguments and RTS parameters. The program's two threads evaluate the same data, the parent thread typically blocks on a blackhole created by a forked child thread. Note the sequence around user event "child": The log written by GHC-7.6.3 correctly shows blocking on a black hole, while the log written by GHC-7.8.2 claims the main thread blocks "on I/O read". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 09:34:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 09:34:47 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.8b1f555325879cf7520ab88e84a0b72a@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by jberthold): * cc: jberthold (added) Comment: Like the GHC-6.x tid field length problem, any solution to the problem requires baking in knowledge of GHC version differences into ghc-events (might break other software that writes event log format). A fix in ghc-events is possible (the fork ghc-events-parallel has been fixed like this as a temporary solution): EVENT_USER_MARKER was added after the 7.6 branch, so the ghc-events parser can use it as an indication to use different thread stop state decoders. When fixing it like this, however, older tools will always yield the error. OTOH, when reverting to the original encoding in GHC (fix inside GHC), one needs to reliably detect GHC-7.8.2 and distinguish it from subsequent versions. Again by adding a new event type in master and GHC-7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 09:50:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 09:50:16 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.33581ea55a3d4ad10852c4d81c3bb55c@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by ezyang): * cc: ezyang (added) Comment: Oof, sorry about breaking backwards compatibility in such an annoying way. I am sympathetic, but it is not clear to me what the correct path from here is. Here are some possibilities: 1. Accept that `includes/Constants.h` really is GHC internal and subject to change however we like (`f30d527344db528618f64a25250a3be557d9f287` is an example of another commit which changed numbering, so my commit is definitely in keeping with tradition), and setup `ghc-events` to match on the relevant GHC version and change its behavior appropriately. I guess we'd need to tag eventlog with the relevant GHC version (I hope we're doing that already...) To take things a step further, since ghc-events would be GHC specific, we might fold it into the GHC build tree, so it tracks changes with the rest of GHC (this might not be so appropriate as you might process eventlogs produced by one version of GHC with another version.) 2. Establish the constants as a proper ABI which we guarantee the stability of, and add comments and test-cases to prevent people from renumbering them to maintain cleanliness. We can take this further and consider the state of affairs in 7.8.2 to be a bug, and renumber back to the original version. (I believe this is your proposal.) `ghc-event` only needs to work around this particular version. (I think version numbers should be added to the eventlog format anyway.) Note: some of the fields we use these constants for are fixed size, so if we never reuse numbers we may run out of space, so we may eventually need to reuse some of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 09:59:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 09:59:31 -0000 Subject: [GHC] #8996: mark more things as const in C codegen In-Reply-To: <045.8247ddb295df41a75076302911e81bc2@haskell.org> References: <045.8247ddb295df41a75076302911e81bc2@haskell.org> Message-ID: <060.e7e96fa78f3ee4a6fd62eae432f1d875@haskell.org> #8996: mark more things as const in C codegen ---------------------------------------+----------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.2 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 slyfox): * difficulty: Easy (less than 1 hour) => Unknown Comment: This patch attempts to mark everything ghc knows as RODATA, what raises a couple of questions: Patch can be tested as './configure --enable-unregisterised' in amd64. Example of build failure: {{{ HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Types.o In file included from /tmp/ghc26762_0/ghc26762_1.hc:3:0: /tmp/ghc26762_0/ghc26762_1.hc:295:6: error: conflicting types for 'ghczmprim_GHCziTypes_False_closure' CEI_(ghczmprim_GHCziTypes_False_closure); ^ /home/slyfox/dev/git/ghc/includes/Stg.h:213:52: note: in definition of macro 'CEI_' #define CEI_(X) extern const StgWordArray (X) GNU_ATTRIBUTE(aligned (8)) ^ /tmp/ghc26762_0/ghc26762_1.hc:27:9: note: previous definition of 'ghczmprim_GHCziTypes_False_closure' was here StgWord ghczmprim_GHCziTypes_False_closure[] = { ^ }}} GHC thinks that extern points to rodata, but actually place or to .data (rwdata). I think it's due to '''rts/StgMiscClosures.cmm''': {{{ /* put these in the *data* section, since the garbage collector relies * on the fact that static closures live in the data section. */ #if !(defined(COMPILING_WINDOWS_DLL)) section "data" { stg_CHARLIKE_closure: CHARLIKE_HDR(0) CHARLIKE_HDR(1) CHARLIKE_HDR(2) CHARLIKE_HDR(3) ... }}} Is it an absolute need to use mutable data section for it? Could GC be tuned to scan for certain rodata block? Or if it's not an option, fix ghc to know that those closure externs are really in "data" section. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 10:29:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 10:29:26 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.ce21e2c2a0081fe2aeb6f0d9f059ce16@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jberthold): Replying to [comment:2 ezyang]: > Oof, sorry about breaking backwards compatibility in such an annoying way. I think we should have some "warning signs" in the code (includes/rts/Constants.h), otherwise this will happen again sooner or later. The shared knowledge of ghc-events and GHC runtime system is in includes/rts/EventLogFormat, which is obviously not up to date right now. includes/rts/Constants.h should point there. About the options: > 1. Accept that `includes/Constants.h` really is GHC internal Decidedly not the intention (for the parts mentioned in EventLogFormat.h). The other commit you found is interesting... My best guess is tha "Relocated" was never actually written to an event log (I might be wrong, though...) > 2. Establish the constants as a proper ABI which we guarantee the stability of, and add comments and test-cases to prevent people from renumbering them to maintain cleanliness.We can take this further and consider the state of affairs in 7.8.2 to be a bug, This is what Simon thought of, judging from what he replied to my mail earlier. I completely agree with you, there have to be comments in the code to avoid this in the future. Then either 2a) ghc-events stays as it is and will never parse ghc-7.8.2 eventlogs 100% correctly 2b) GHC and ghc-events are adapted to recognise ghc-7.8.2 traces (and not later versions) from their header, by adding an event or extending one with a new field, in GHC-7.8.3. Or there might be 3. Consider older ghc-events versions outdated (something we wanted to avoid), and only adapt ghc-events. This is what I did for the fork ghc- events-parallel (but it leaves the route to 2B open). And: Yes, an event indicating the RTS version is written by (newer versions of) GHC. However, we cannot rely on it being present, and it is fiddly/fragile to read the beginning of an eventlog and then switch parsers when (and iff) it is found. I tried that, but then went for the other fix. The information must be derived from the header (event information), not from events that may or may not be written. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 10:38:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 10:38:00 -0000 Subject: [GHC] #8996: mark more things as const in C codegen In-Reply-To: <045.8247ddb295df41a75076302911e81bc2@haskell.org> References: <045.8247ddb295df41a75076302911e81bc2@haskell.org> Message-ID: <060.a00ca77400478257ebdb7eddd82fb6e0@haskell.org> #8996: mark more things as const in C codegen ---------------------------------------+----------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by ezyang): The comment dates back to GHC 4.01, so it might be wrong; I can't think of any reason for the GC to be doing any scribbling here (Chars and Ints are NOCAF, so we don't need to link them together on the static_objects list; ditto for all of the other similar miscellaneous closures.). Maybe Simon knows better. In any case, it will be a moot point when is #8199 fixed, after which "static closures" absolutely must be writable since we need to update them to indirect onto blocks we've allocated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 10:47:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 10:47:25 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.a130d5c4249db6fb37e03edabd72f87c@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ezyang): Here's another perspective: really this is just a bug in this function implementation: {{{ INLINE_HEADER void traceEventStopThread(Capability *cap STG_UNUSED,? StgTSO *tso STG_UNUSED,? StgThreadReturnCode status STG_UNUSED, StgWord32 info STG_UNUSED) { traceSchedEvent2(cap, EVENT_STOP_THREAD, tso, status, info); dtraceStopThread((EventCapNo)cap->no, (EventThreadID)tso->id, (EventThreadStatus)status, (EventThreadID)info); } }}} We shouldn't cast from `StgThreadReturnCode` to `EventThreadStatus`, really we should have some translation function from one to the other (coded in terms of the constants, so updating `Constants.h` works automatically). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 11:16:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 11:16:29 -0000 Subject: [GHC] #9001: unexpected runtime crash In-Reply-To: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> References: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> Message-ID: <060.b209ca8221c40879d9f60398e4dd6894@haskell.org> #9001: unexpected runtime crash -------------------------------------+------------------------------------ Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I can reproduce this behavior on Mac OS 10.8.5 & GHC 7.8.2. After a bunch of (presumably expected) output, I get {{{ Test: internal error: scavenge_one: strange object 0 (GHC version 7.8.2 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 11:37:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 11:37:01 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.83eea60db5819f5fb671888513fea04f@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): Yeah, so regarding 1* from comment19, that was just me being very silly, I'll upload a patch that fixes that soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 14:08:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 14:08:55 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.744e173e8e5914dd58327a9456658fba@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): Re recursive flags, promotable, etc, the usual convention is to print that kind of stuff when `-dppr-debug` is enabled. Let's just do that for now. I was expecting you to say that a type like `Ord a => a -> Bool` is printing as `Ord a -> a -> Bool`, which isn't what the user of GHCi expects. Isn't that happening? To solvet hat I propose that we add a new constructor `IfaceDFunTy` to `IfaceType`, that behaves exactly like `IfaceFunTy` except that it prints differently. Re (2) that's an example of a bump in the road, and one I was expecting. I think it amounts to saying that the `ifAxiom` field of the `IfaceData` constructor doesn't have enough information to print nicely. One possibility is to add that information; it's kind of redundant (in the same way as `IfaceDFunTy`, but helps printing. But first, why are we calling `pprTyThing` on a family instance tycon? Does this case show up in practice? If so, how? I'd expect it to be more common to print a `IfaceFamInst`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 15:01:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 15:01:09 -0000 Subject: [GHC] #9001: unexpected runtime crash In-Reply-To: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> References: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> Message-ID: <060.d79fd58d99380eec0a1dd161a86f7e5e@haskell.org> #9001: unexpected runtime crash -------------------------------------+------------------------------------ Reporter: jwlato | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by rwbarton): * cc: simonmar (added) * owner: => simonmar * component: Compiler => Runtime System Comment: I can reproduce it on Linux also. It seems to be related to stack overflow handling somehow: when I run with `-k1M` the program completes successfully (even with the `-Dg` and `-DS` debug options too). (Though it could still be either a bug in the runtime system or a bug in the code generation.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 15:32:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 15:32:24 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.979543eb96a9a8d18ade0943599c1156@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): Regarding (2), currently ifAxiom just gets the name of the axiom, so as you say we could also get the name from the ``` TyCon ``` and other info we need, that's what I was working on now but it just doesn't feel right to add all that redundant information in there.```pprTyThing``` gets called on a family instance tycon because when we request info about a data constructor of a family instance we call ```tyThingParent_maybe``` that will return the immediate parent and in this case it is the family instance tycon. We could bypass this and instead return a ``` FamInst ``` in the appropriate case, like this we don't need to add any extra info to ``` IfaceData ```. ```tyThingParent_maybe``` is only used for pretty printing so if you think this is a good idea it will not complicate things ? Regarding the context printing properly I thought that needs no mentioning because you suggested how it should be fixed in another comment here and in #8876, I just wanted to get these other things right first. Andrei -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 18:22:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 18:22:09 -0000 Subject: [GHC] #9004: Add sortOn function to Data.List Message-ID: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> #9004: Add sortOn function to Data.List -------------------------------------------+------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 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: -------------------------------------------+------------------------------- The following passed for two weeks on the libraries mailing list without any dissenting votes. The request is to add the following function to Data.List: {{{ -- | Sort a list by comparing the results of a key function applied to each -- element. @sortOn f@ is equivalent to @sortBy . comparing f@, but has the -- performance advantage of only evaluating @f@ once for each element in the -- input list. This is called the decorate-sort-undecorate paradigm, or -- Schwartzian transform. sortOn :: Ord b => (a -> b) -> [a] -> [a] sortOn f = map snd . sortBy (comparing fst) . map (\x -> let y = f x in y `seq` (y, x)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 18:27:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 18:27:23 -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.e1c51c8c085127dc2e347a25ea51bc62@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 simonmic): * cc: simon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 21:13:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 21:13:49 -0000 Subject: [GHC] #9001: unexpected runtime crash In-Reply-To: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> References: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> Message-ID: <060.b98c968aa3c84cb334540813c4dac652@haskell.org> #9001: unexpected runtime crash -------------------------------------+------------------------------------ Reporter: jwlato | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): It looks like the stack overflows in a long sequence of `stg_ap_*` function calls and the overflow isn't detected until a point at which `Sp` is not only less than `SpLim` but even less than the start of the stack segment, whereupon bad things happen. Isn't it bad that these `stg_ap_*_fast` functions push things onto the stack without checking for overflow? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 16 21:15:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Apr 2014 21:15:04 -0000 Subject: [GHC] #9001: unexpected runtime crash In-Reply-To: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> References: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> Message-ID: <060.1797b96036b08fde0bbdd4781e24a6bb@haskell.org> #9001: unexpected runtime crash -------------------------------------+------------------------------------ Reporter: jwlato | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): I've reduced the testcase, but it got messy; compiling `ghc-7.8.2 X.hs` and running should give an internal error: {{{ {-# LANGUAGE RankNTypes #-} newtype FMList = FM {unFM :: forall m. (m -> m -> m) -> m -> m} main = print $ build $ delete $ FM (\_ x -> x) delete l = FM (\map x -> unFM l const (const undefined) `seq` unFM (delete (dr l)) map x `seq` x) build t = unFM t (.) (+1) 0 dr t = FM $ \_ g -> unFM t (.) (const g) undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 02:45:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 02:45:35 -0000 Subject: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate In-Reply-To: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> References: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> Message-ID: <061.cdc74fd3564663a11a26aa95efeceb27@haskell.org> #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4139 -------------------------------------+------------------------------------ Comment (by cactus): I was asked about the following program failing to compile. Do you think this is also caused by the same underlying problem? {{{ {-# OPTIONS_GHC -fwarn-incomplete-patterns -Werror #-} {-# LANGUAGE GADTs, TypeFamilies #-} type family F a type instance F a = () data Foo a where FooA :: Foo () FooB :: Foo Int f :: a -> Foo (F a) -> () f _ FooA = () }}} The error/warning is, of course: {{{ gadt-incomplete.hs:12:1: Warning: Pattern match(es) are non-exhaustive In an equation for `f': Patterns not matched: _ FooB }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 03:07:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 03:07:06 -0000 Subject: [GHC] #9005: Ship default bash completion file with ghc Message-ID: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> #9005: Ship default bash completion file with ghc ------------------------------------+------------------------------------- Reporter: td123 | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: None | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Now that ticket #7843 has been closed, it would be great to ship a default implementation of a bash completion file for ghc. Since there isn't a standard location to install completion files across distros, it might be good to have an optional flag during configure to specify a location and if one is specified, install the bash completion file into that location. The following links provide implementations that have worked for me: http://www.reddit.com/r/haskell/comments/236qkb/autocomplete_command_line_options_with_ghc_78/ https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 03:07:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 03:07:06 -0000 Subject: [GHC] #9006: Ship default bash completion file with ghc Message-ID: <044.322ab3dfc8171fa184d790f042f4a4f0@haskell.org> #9006: Ship default bash completion file with ghc ------------------------------------+------------------------------------- Reporter: td123 | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: None | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Now that ticket #7843 has been closed, it would be great to ship a default implementation of a bash completion file for ghc. Since there isn't a standard location to install completion files across distros, it might be good to have an optional flag during configure to specify a location and if one is specified, install the bash completion file into that location. The following links provide implementations that have worked for me: http://www.reddit.com/r/haskell/comments/236qkb/autocomplete_command_line_options_with_ghc_78/ https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 03:24:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 03:24:21 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.9722abd1391a180ed06ba57b02c374c6@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by td123): Replying to [comment:7 hvr]: > Strange, `transformers` and `hoopl` shouldn't be in that list (i.e. as mentioned earlier in this ticket, only `haskeline`,`terminfo`, and `xhtml` are problematic), as those are actually needed by the `ghc` package (and they will show up in `ghc-pkg list` for a properly performed GHC installation) Ah, this is my fault for looking at the list of files installed. If we are only talking about {{{ ghc-pkg list }}} then I get the following lines on a fresh install: {{{ /usr/lib/ghc-7.8.2/package.conf.d Cabal-1.18.1.3 array-0.5.0.0 base-4.7.0.0 bin-package-db-0.0.0.0 binary-0.7.1.0 bytestring-0.10.4.0 containers-0.5.5.1 deepseq-1.3.0.2 directory-1.2.1.0 filepath-1.3.0.2 ghc-7.8.2 ghc-prim-0.3.1.0 haskell2010-1.1.2.0 haskell98-2.0.0.3 hoopl-3.10.0.1 hpc-0.6.0.1 integer-gmp-0.5.1.0 old-locale-1.0.0.6 old-time-1.1.0.2 pretty-1.1.1.1 process-1.2.0.0 rts-1.0 template-haskell-2.9.0.0 time-1.4.2 transformers-0.3.0.0 unix-2.7.0.1 }}} So I guess the only problems I actually have are the hoopl and transformer packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 03:48:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 03:48:35 -0000 Subject: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate In-Reply-To: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> References: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> Message-ID: <061.24992df320cb46810f84aa965d724c6f@haskell.org> #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4139 -------------------------------------+------------------------------------ Changes (by cactus): * cc: gergo@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 03:49:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 03:49:59 -0000 Subject: [GHC] #9005: Ship default bash completion file with ghc In-Reply-To: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> References: <044.36e9f7350e06cce5a30d1a2bcf83acd9@haskell.org> Message-ID: <059.1cd2eae6bdc0300035df71d5064e2170@haskell.org> #9005: Ship default bash completion file with ghc -------------------------------------+------------------------------------ Reporter: td123 | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: None | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): (I deleted the duplicate ticket.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 07:23:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 07:23:20 -0000 Subject: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate In-Reply-To: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> References: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> Message-ID: <061.59d78eb67dedc16d0b93dcd2ae072aa7@haskell.org> #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4139 -------------------------------------+------------------------------------ Comment (by simonpj): Yes, I think it's the same thing, though this time you have do some type- family rewrites too, to see that the patterns are exhaustive. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 09:27:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 09:27:32 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.b9f0c8bcb0194dbc3e48b15a9b2d613e@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): Thinking about this some more, I think the best thing is to include the `fam_tc` and `arg_tys` in the `ifAxiom` field, and maybe rename it thus: {{{ ifParent :: IfaceTyConParent }}} where {{{ data IfaceTyConParent = IfNoParent | IfDataInstance IfExtName -- Axiom IfExtName -- Parent TyCon [IfaceType] -- Arg tys }}} That would make `tc_parent` in `TcIface` a lot simpler too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 10:15:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 10:15:51 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception In-Reply-To: <044.4c21331b0c5897214741257d5027da6d@haskell.org> References: <044.4c21331b0c5897214741257d5027da6d@haskell.org> Message-ID: <059.8032c74f2b1b2d1d43d2614da3377816@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 Simon Peyton Jones ): In [changeset:"241c6601568969156403fde8089c97024b082de0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="241c6601568969156403fde8089c97024b082de0" Make qReport force its error message before printing it Fixes Trac #8987. See Note [Exceptions in TH] Thanks to Yuras Shumovich for doing this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 11:26:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 11:26:38 -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.b59128a70a0cae17681141a7a9633db4@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by nomeata): Is this related to the failure {{{ configure: Building in-tree ghc-pwd /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status configure: error: Building ghc-pwd failed }}} at http://deb.haskell.org/dailies/2014-04-16/ghc_7.9.20140416-0.daily_amd64.build which prevents up-to-date packages to appear in on deb.haskell.org? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 14:30:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 14:30:38 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.df8e3f659ff87013bcbcaa5eb2522f80@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by td123): Investigated this some more this morning: The following commits look like they wanted to make transformers and hoopl installed with ghc on purpose: "Ship transformers with GHC" https://github.com/ghc/ghc/commit/71feb1025eed0c3cc849c85e2b00e16bc1a21790 "Merge in new code generator branch" (introduces hoopl) https://github.com/ghc/ghc/commit/889c084e943779e76d19f2ef5e970ff655f511eb And looking back at the 7.8.1 release notes, hoopl is mentioned as a package. http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/release-7-8-1.html But it doesn't look like transformers is mentioned. So I'm not sure if this is an issue anymore. Looks like they were both meant to be added to ghc. Hoopl is mentioned in the release notes. But transformers isn't but it seems like it should be. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 15:01:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 15:01:19 -0000 Subject: [GHC] #9006: GHC accepts import of private data constructor if it has the same name as the type Message-ID: <046.f4fcc91a133451d6f840223341c96eb9@haskell.org> #9006: GHC accepts import of private data constructor if it has the same name as the type --------------------------+------------------------------------------------ Reporter: | Owner: Lemming | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ {{{ $ cat A.hs B.hs module A (T) where data T = T module B where import A (T(T)) }}} `ghci-7.8.2` accepts module B, whereas `ghci-7.6.3` and `ghci-7.4.2` say: {{{ B.hs:3:11: Module `A' does not export `T(T)' }}} For this bug to happen it is important, that the data constructor has the same name as the type. I.e. if you rename the data constructor to, say, `Cons`, then `ghci-7.8.2` will emit the same error as earlier versions. The bug is not dramatic, since if you try to actually use the imported data constructor then ghc will say {{{ B.hs:20:5: Not in scope: data constructor ?T? }}} However this error message is very confusing, because it suggests that `T` is not in scope although you imported it correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 18:53:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 18:53:04 -0000 Subject: [GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) In-Reply-To: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> References: <048.b7e4ab0814cc36ecf0cb90a86925739b@haskell.org> Message-ID: <063.780bc4d0ca0ed01f1b02dc67980bf6c7@haskell.org> #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------+------------------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonmar): I agree with Edward. The fact that the thread statuses are written verbatim into the event log is the real bug here, because it ties the thread status values to the event log format, whereas they ought to be an internal implementation detail. We only did it this way in the first place because we are lazy (that's the royal "we"). So I propose we fix it in 7.8.3. That is, revert to the original numbering in the event log. But do it with a big switch statement in `traceEventStopThread`, rather than undoing the patch that reordered the numbers. Then we won't have this problem again. Whether ghc-events is patched to work with 7.8.2 or not is a separate matter. It would be good to do this, but it doesn't change the fact that existing ghc-events (and ThreadScope) will give strange results with 7.8.2. If ghc-events is fixed, I'd much rather it was done by looking at the version number rather than inferring it from something else. Is that really too hard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 18:54:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 18:54:42 -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.15a43260e6ce85371e7f7693946c7165@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by simonmar): No, that's different. What `LDFLAGS` are being passed to configure? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 19:02:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 19:02:34 -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.e859b124fc75cc4f76184f1a3b933f0f@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 19:54:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 19:54:55 -0000 Subject: [GHC] #9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object Message-ID: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> #9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object ----------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Building HEAD on Debian wheezy with the Debian packaging setup fails: {{{ configure: Building in-tree ghc-pwd /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status configure: error: Building ghc-pwd failed }}} http://deb.haskell.org/dailies/2014-04-16/ghc_7.9.20140416-0.daily_amd64.build This is possibly related to the Hardening flags added by Debian: {{{ ~ $ dpkg-buildflags --get LDFLAGS -Wl,-z,relro ~ $ dpkg-buildflags --get CFLAGS -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror =format-security }}} Other related bug might be #3668 and https://bugs.debian.org/712228 I?ll disable the hardening flags and see if it helps. The error first occurred 2014-03-27. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 19:55:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 19:55:40 -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.6b6f9ff33af9832c7989dbb7d7057721@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by nomeata): > No, that's different. What LDFLAGS are being passed to configure? Ok, reported as #9007. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 22:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 22:14:33 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator Message-ID: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> #9008: Data.Function: Add reverse application operator ------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 17 22:16:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Apr 2014 22:16:31 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.1156e2bad4fbbd9a3c16a7146bd5272f@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by bernalex): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 05:45:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 05:45:29 -0000 Subject: [GHC] #9009: Confusing error message when loading package with TH Message-ID: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> #9009: Confusing error message when loading package with TH ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I got this error message when compiling a file that calls Template Haskell function from `singletons` package: {{{ [1 of 1] Compiling Splices ( Splices.hs, Splices.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package pretty-1.1.1.1 ... 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.5.1 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-0.4.1 ... linking ... done. Loading package th-desugar-1.4.0 ... linking ... done. Loading package singletons-1.0 ... : can't load .so/.DLL for: /home/killy/.cabal/lib/x86_64-linux- ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so (/home/killy/.cabal/lib/x86_64-linux- ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so: undefined symbol: singletonszm1zi0_DataziSingletonsziSingleziMonad_lookupProxy1_info) }}} After some investigation it turned out that the module Data.Singletons.Single.Monad was not listed in singletons.cabal file - neither under exported-modules nor other-modules - when the package was installed. The error message is mostly confusing. It would be good to at least get a hint on the possible cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 06:26:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 06:26:12 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.335164f397f6f9a76e335c2f18e79b27@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: patch => closed * resolution: => invalid Comment: Adding functions to base libraries need to be discussed and agreed on on the libraries@ mailing list. After it's approved, please provide a link to the mailing list discussion together with the patch. For this particular issue (adding a reverse function application operator) I believe there have been about 10^10 discussion and every single one have ended with "no", which is why we don't have a reverse function application operator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 07:15:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 07:15:23 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.34bdd6c70694a36c5c0b038cb264dd1c@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: ekmett (added) * status: closed => new * resolution: invalid => Comment: This was already approved by the core libraries committee including Edward (I've CC'd him on the ticket for reference), and the date of approval is in the commit. I guess Alex merely forgot to put a reference in the actual ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 07:24:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 07:24:24 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.a5cc07df93706b1e3b3eefd04d93cbdd@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jstolarek): > please provide a link to the mailing list discussion Forgive the off-topic, but does library mailing list finally have a web archive so that it can be linked to? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 07:25:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 07:25:59 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.a322e0efe8c2b959b4c99c72805e4055@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bernalex): Replying to [comment:4 jstolarek]: > Forgive the off-topic, but does library mailing list finally have a web archive so that it can be linked to? Yes, . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 07:33:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 07:33:56 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.ed9e4d08b6516933322e8681bd1e6156@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jstolarek): Interesting. Looks like the archive was always there. I recall several months ago no one on #ghc channel was able to point to it and Google also didn't find anything. Everyone was convinced that it does not exist and considered it a major pain. Well, that must've been a misunderstanding. Thanks for clearing that up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 07:48:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 07:48:32 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.76274df55210fb4a090c0075f023695a@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:6 jstolarek]: > Interesting. Looks like the archive was always there. I recall several months ago no one on #ghc channel was able to point to it and Google also didn't find anything. Everyone was convinced that it does not exist and considered it a major pain. Well, that must've been a misunderstanding. Thanks for clearing that up. Btw, that could have been about the internal core-library-committee list, whose archives [https://www.mail-archive.com/haskell- infrastructure at community.galois.com/msg00055.html were/are not publicly available]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 07:53:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 07:53:12 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.23713953af0a49ca64f0601b56ab40e2@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jstolarek): Ah, yes! You're right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 08:41:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 08:41:15 -0000 Subject: [GHC] #3549: unlit does not follow H98 spec In-Reply-To: <045.eacb9764be0b8b701a8c620148ff0200@haskell.org> References: <045.eacb9764be0b8b701a8c620148ff0200@haskell.org> Message-ID: <060.583a02d25d105839111a751aedaed20c@haskell.org> #3549: unlit does not follow H98 spec -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: ? 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: -------------------------------------+------------------------------------ Comment (by mgsloan1): Figured I'd unearth this ticket to add a few notes, since I was recently looking into how ghc's lhs support behaves. I found some additional quirks: * It's valid to add trailing whitespace after `\begin{code}` or `\end{code}`. I think that's due to this line: https://github.com/ghc/ghc/blob/master/utils/unlit/unlit.c#L224 * It's valid to indent `\begin{code}`, but not `\end{code}`. I think the whitespace before `\begin{code}` is consumed by https://github.com/ghc/ghc/blob/master/utils/unlit/unlit.c#L214 . `\end{code}`, on the other hand is recognized by strncmp: https://github.com/ghc/ghc/blob/master/utils/unlit/unlit.c#L276 RE igloo's comment, I agree that unlit should not need to know that `\end{code}` is inside a string literal. It's unreasonable to mix up tokenization and unlit like that, particularly when you consider writing tools external to ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 08:59:11 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 08:59:11 -0000 Subject: [GHC] #9010: TemplateHaskell leads to an "unknown symbol" error Message-ID: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error ------------------------------------+------------------------------------- Reporter: Feuerbach | 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: | ------------------------------------+------------------------------------- Code: {{{ {-# LANGUAGE TemplateHaskell #-} module M where import System.Console.Editline import Data.Lens.Template data S = S { _a :: EditLine } makeLens ''S }}} When compiled with `ghc link.hs`, everything is fine; {{{ [1 of 1] Compiling M ( link.hs, link.o ) 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 containers-0.5.0.0 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package tagged-0.7.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-compat-0.1.1.1 ... linking ... done. Loading package contravariant-0.4.4 ... linking ... done. Loading package distributive-0.4.3.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package nats-0.1.2 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package semigroups-0.12.2 ... linking ... done. Loading package comonad-4.0.1 ... linking ... done. Loading package semigroupoids-4.0.1 ... linking ... done. Loading package data-lens-2.10.4 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package data-lens-template-2.1.8 ... linking ... done. }}} However, when compiling with `ghc -package-id editline-0.2.1.1-ef91ae78e7ea1b9142c2fb0b84e85c11 link.hs`, I get {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package editline-0.2.1.1 ... linking ... ghc: /home/feuerbach/work /.cabal-sandbox/lib/i386-linux- ghc-7.6.3/editline-0.2.1.1/HSeditline-0.2.1.1.o: unknown symbol `el_reset' ghc: unable to load package `editline-0.2.1.1' }}} This is a problem because that's how cabal invokes ghc. This looks similar to #4899, except there's nothing "non-standard" here (no profiling or dynamic linking). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 10:57:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 10:57:17 -0000 Subject: [GHC] #9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.6044341f2f270d7563691a3441a4f612@haskell.org> #9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 11:00:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 11:00:55 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.23d1b4b664fcef54266f8393ce551a97@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bernalex): Replying to [comment:2 tibbe]: > please provide a link to the mailing list discussion together with the patch I can't find a link. Sorry. I guess the announcement was on the internal closed list. It was likely following this[0] discussion. Edward refers to it in [1]. Hopefully this is satisfactory evidence for now. I leave it to Edward or others to provide more information. [0] [1] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 11:10:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 11:10:22 -0000 Subject: [GHC] #9001: unexpected runtime crash In-Reply-To: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> References: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> Message-ID: <060.442fc92752f11a649046b28c461530ec@haskell.org> #9001: unexpected runtime crash -------------------------------------+------------------------------------ Reporter: jwlato | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * priority: normal => highest * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 12:16:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 12:16:35 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.05bfb9809dd9092e2c832550ebe2cf1d@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek 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 jstolarek): Inserting a call to `checkValidTheta` after the theta has been zonked (in `tcPolyInfer`) indeed does the job but I can't solve one problem. `checkValidTheta` requires `UserTypeCtxt` parameter. I assume that in this case the value should be `InfSigCtxt`, since we are dealing with inferred signature. The problem is that `InfSigCtxt` requires name of function for which the type has been inferred. This information doesn't seem to be easily available inside `tcPolyInfer`. I noticed that the name is stored inside `name_taus` so I did a hack that calls `checkValidTheta (InfSigCtxt (fst . head $ name_taus)) theta`. In this particular case it works because `fold` name is stored as first in the list. But I don't know what is a general solution for finding name of function for which we are inferring the signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 20:16:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 20:16:26 -0000 Subject: [GHC] #9001: unexpected runtime crash In-Reply-To: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> References: <045.0c5b9389579d37285a1d0510eeaeacdb@haskell.org> Message-ID: <060.a0dd77e18bd13f2fd7693ebd6eb6a58e@haskell.org> #9001: unexpected runtime crash -------------------------------------+------------------------------------ Reporter: jwlato | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Yes, it looks like missing stack checks in the `stg_ap_*_fast` functions. I'm looking into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 15:04:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 15:04:53 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) (was: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.ceaacabf1114990e62f01ee924795804@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by nomeata): Yes, without the hardening flags it builds. So it is likely caused by 2aa78106ae8f3c9b71d7b85c2a8a5558c4c35fb4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 20:43:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 20:43:44 -0000 Subject: [GHC] #9004: Add sortOn function to Data.List In-Reply-To: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> References: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> Message-ID: <065.9250b17e4dda6ec6a43624ab6214f0d2@haskell.org> #9004: Add sortOn function to Data.List -------------------------------+------------------------------------------- Reporter: | Owner: JohnWiegley | Status: patch Type: feature | Milestone: 7.10.1 request | Version: 7.8.2 Priority: normal | Keywords: Component: | Architecture: Unknown/Multiple libraries/base | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by bernalex): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 21:38:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 21:38:00 -0000 Subject: [GHC] #9004: Add sortOn function to Data.List In-Reply-To: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> References: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> Message-ID: <065.b093c9dac6b7cf5d434233d2f6b05927@haskell.org> #9004: Add sortOn function to Data.List -------------------------------+------------------------------------------- Reporter: | Owner: JohnWiegley | Status: patch Type: feature | Milestone: 7.10.1 request | Version: 7.8.2 Priority: normal | Keywords: Component: | Architecture: Unknown/Multiple libraries/base | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by bernalex): I forgot to add the bug number to the commit message. Please use the latter patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 21:38:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 21:38:10 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.ea48a44527e977d3d981b2dbece0a1f3@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bernalex): I forgot to add the bug number to the commit message. Please use the latter patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 21:53:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 21:53:13 -0000 Subject: [GHC] #4413: (^^) is not correct for Double and Float In-Reply-To: <056.b95b95b9854cc31706fe2ec11ee3d940@haskell.org> References: <056.b95b95b9854cc31706fe2ec11ee3d940@haskell.org> Message-ID: <071.538460deae73840cffa503bffc97b3e4@haskell.org> #4413: (^^) is not correct for Double and Float -------------------------------------+------------------------------------- Reporter: | Owner: tcsavage daniel.is.fischer | Status: new Type: bug | Milestone: 7.6.2 Priority: low | Version: 7.1 Component: libraries/base | Keywords: Double, Float, Resolution: | exponentiation Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Unknown at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett@?, hvr (added) * difficulty: => Unknown Comment: When I first saw this, I was in favor of it, but then I chewed on it some more. The issue is unfortunately more subtle. While Daniel's proposal is sound for 2 and 0.5 which have exact representations in IEEE 754 floating point for both the original number and the reciprocal, this proposal yields worse numeric precision for any floating point number where the inverse isn't exactly representable. Consider 3. {{{ >>> recip 3^600 5.336385165377033e-287 >>> recip (3^600) 5.336385165377108e-287 }}} Now, lets compare these to answers that are more accurate, using my `rounded` library: {{{ >>> :m + Numeric.Rounded >>> :set -XDataKinds >>> recip (3^600) :: Rounded TowardZero 512 5.3363851653771076591089513443334745430695010187597757569958309540684063019552892464056775485633511783044398629355030763271677070438623409480523609685251156e-287 >>> recip 3^600 :: Rounded TowardZero 512 5.3363851653771076591089513443334745430695010187597757569958309540684063019552892464056775485633511783044398629355030763271677070438623409480523609685247316e-287 }}} The inexact version caused us 3 decimal places worth of accuracy. Those 10 bits of lost significand dwarf the error in the subnormal case. If we're stuck choosing, the existing implementation shoots an arrow that consistently winds up closer to the mark except in cases of underflow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 21:58:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 21:58:59 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.2d7419f2bfc2ca82dc948c8635d33b9d@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ekmett): * cc: ekmett@?, hvr (added) * difficulty: => Unknown Comment: This makes sense to me. I'm personally, in favor of fixing it to be correct first, then opening an issue that it could be faster, as what we are doing now is incorrect. It doesn't matter how fast you do your job if you do the wrong job. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 22:08:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 22:08:57 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.11e3896b9d944965648de1d701cb9f43@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ekmett): Actually I was talking about a different committee with non-publicly available mailing list. =) With the `core-libraries-committee` we're setting up a bug tracker so you'll be able to link from issues like this to appropriate resolutions. When this last arose I spoke to `hvr` about us using the github issue tracker for `base`, but that was put on hold due to the decision to fold base into the `ghc` repository. I suppose it is time to just give in and use a trac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 22:42:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 22:42:37 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.bd91ac169aa038ec567f960ea43fbb04@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek 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 simonpj): Well if you have {{{ f x = g x g x = f (h x) }}} then `tcPolyInfer` will be called on the two bindings together. If you happened to get a badly-shaped inferred theta, do you want to report an error for f, or for g, or both? I think just one would do, which is what you have implemented. If you want one per function, put the check in `mkExport` instead. Either way it's not a big deal. Comments, with an example, would be a Good Thing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 23:30:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 23:30:07 -0000 Subject: [GHC] #9006: GHC accepts import of private data constructor if it has the same name as the type In-Reply-To: <046.f4fcc91a133451d6f840223341c96eb9@haskell.org> References: <046.f4fcc91a133451d6f840223341c96eb9@haskell.org> Message-ID: <061.3f4a6f9017265cee33b9d0b2254abde2@haskell.org> #9006: GHC accepts import of private data constructor if it has the same name as the type ------------------------------------------------+-------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: rename/should_fail/T9006 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => closed * testcase: => rename/should_fail/T9006 * resolution: => fixed Comment: Excellent point, thank you. We could merge the fix to the 7.8 branch, but I'm not sure it's worth the bother Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 18 23:30:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Apr 2014 23:30:36 -0000 Subject: [GHC] #9006: GHC accepts import of private data constructor if it has the same name as the type In-Reply-To: <046.f4fcc91a133451d6f840223341c96eb9@haskell.org> References: <046.f4fcc91a133451d6f840223341c96eb9@haskell.org> Message-ID: <061.73923190272670d446f9ece86912c2fd@haskell.org> #9006: GHC accepts import of private data constructor if it has the same name as the type ------------------------------------------------+-------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: rename/should_fail/T9006 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonpj): Here's the commit {{{ commit f964cd9c5c411f8a2383cf2b080581a5c3349661 Author: Simon Peyton Jones Date: Fri Apr 18 23:30:18 2014 +0100 Take account of the AvailTC invariant when importing In the rather gnarly filterImports code, someone had forgotten the AvailTC invariant: in AvailTC n [n,s1,s2], the 'n' is itself included in the list of names. compiler/rename/RnNames.lhs | 80 +++++++++++++++---------- testsuite/tests/rename/should_fail/T9006.hs | 3 + testsuite/tests/rename/should_fail/T9006.stderr | 2 + testsuite/tests/rename/should_fail/T9006a.hs | 3 + testsuite/tests/rename/should_fail/all.T | 3 + 5 files changed, 59 insertions(+), 32 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 00:16:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 00:16:40 -0000 Subject: [GHC] #8940: "make help" fails In-Reply-To: <043.56b6e22a9950cbc1198cdc30c7e96b87@haskell.org> References: <043.56b6e22a9950cbc1198cdc30c7e96b87@haskell.org> Message-ID: <058.cf48180c94160867b52a30fb5e7c6605@haskell.org> #8940: "make help" fails -------------------------------------+------------------------------------ Reporter: uznx | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build 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 carter): * milestone: => 7.10.1 Comment: it'd be neat to get this merged into the HEAD / 7.9 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 07:35:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 07:35:57 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.4c484cb72900eb5fd8b5098c989cbe68@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek 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 jstolarek): Before I push my patches let me remark that this is a breaking change. There were files in the main source code as well as boot libraries that required enabling either `FlexibleContexts` or `TypeFamilies` extensions (or both). Error messages are informative so it's easy to fix the code, but when we release GHC 7.10 some user libraries will need to adjust to this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 07:47:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 07:47:22 -0000 Subject: [GHC] #9011: panic - interactiveUI:setBuffering2 Message-ID: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> #9011: panic - interactiveUI:setBuffering2 ----------------------------------+------------------------------- Reporter: irneb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- I've looked through some other tickets and tried installing libffi5, though in my distro (Kubuntu 13.10 x86-64) only libffi6 is available. Even after installing that I get the following: {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): interactiveUI:setBuffering2 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 Sat Apr 19 08:26:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 08:26:30 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.4baa6cf972309e0a352ede907c146b8c@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:"a6e68af1aba7294a18ecb15784d9fe5d90289101/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a6e68af1aba7294a18ecb15784d9fe5d90289101" Fold ghc-prim.git into ghc.git (re #8545) At the time of merge, ghc-prim.git was at [ad9bf96815cb5a9bb4acc51c99eff20be3e50da3/ghc-prim] Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 08:27:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 08:27:39 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.c8ebe3044d59aa9191494b3886be116b@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:"c83bec7853e8f59cb2c5869baf2d2e0179c6c195/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c83bec7853e8f59cb2c5869baf2d2e0179c6c195" Fold base.git into ghc.git (re #8545) At the time of merge, base.git was at [52c0b09036c36f1ed928663abb2f295fd36a88bb/base] Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 08:27:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 08:27:40 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.ab1b2d3b4428f4f79a05858357e87e3d@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:"85febc048d733eb5c8a942e505af26156295f3a6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="85febc048d733eb5c8a942e505af26156295f3a6" Fold integer-simple.git into ghc.git (re #8545) At the time of merge, integer-simple.git was at [9e8b924f68c4cdb6c7ae88f274baa3560aaa305e/integer-simple] Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 08:27:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 08:27:41 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.67bc73089cd984d9a68b5ac6dafa48cc@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:"670599db0df700317eb42ac4f42a841c78ffef5d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="670599db0df700317eb42ac4f42a841c78ffef5d" Fold integer-gmp.git into ghc.git (re #8545) At the time of merge, integer-gmp.git was at [d7bff4dddfa10389156ca11f75a5a23e78cf3ab0/integer-gmp] Note: All but the last/current GMP tarball were removed from the history to keep the Git history size at a minimum. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 08:27:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 08:27:42 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.96b50c8577c49c9bf2cb1f0e6e203b56@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:"8bcb2068e496b36d74c655c868cc93be2de45d94/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8bcb2068e496b36d74c655c868cc93be2de45d94" Fold template-haskell.git into ghc.git (re #8545) At the time of merge, template-haskell.git was at [9bcc122819a6f4a2ae7ad569717324b8368e801c/template-haskell] Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 08:28:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 08:28:41 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.58f2bde2a56b8f8703d84aefa71fa869@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:"41f5b7e3e0648302b9c5dc485917a391d21d15a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="41f5b7e3e0648302b9c5dc485917a391d21d15a1" Update `sync-all` and `packages` wrt to fold-in This adapts `sync-all` and `packages` to the recently folded-in Git repositories - `base.git` - `ghc-prim.git` - `integer-gmp.git` - `integer-simple.git` - `template-haskell.git` See #8545 as well as 5f54d67818ee7a74325eed130438beba96510e43 for more details. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 09:22:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 09:22:03 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.f5100fe4ca6460fbf6dc4806c56311ca@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature -------------------------------------+------------------------------------ Reporter: Blaisorblade | Owner: jstolarek 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 Jan Stolarek ): In [changeset:"1d2ffb6ab1ef973c85f893b5ea4a72cfa59ce484/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1d2ffb6ab1ef973c85f893b5ea4a72cfa59ce484" Validate inferred theta. Fixes #8883 This checks that all the required extensions are enabled for the inferred type signature. Updates binary and vector submodules. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 09:24:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 09:24:39 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.1e799cc59774ca9f715948e42d867b17@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by jstolarek): * status: new => closed * testcase: => typecheck/should_fail/T8883 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 09:52:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 09:52:04 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.14768227127aab1aa6069a067f48da73@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"1bf6c0e482cfe4b9dfa0b5ed18a5741ba44fc226/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1bf6c0e482cfe4b9dfa0b5ed18a5741ba44fc226" Add reverse application operator Data.Function.(&) Add `&` as the reverse application operator with `infixl 1`, which allows it to be nested in `$` (re #9008). Approved by the core libraries committee on 2013-10-14. This also bumps the `base` version number to 4.7.1.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 09:52:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 09:52:05 -0000 Subject: [GHC] #2659: Add sortOn and other *On functions In-Reply-To: <045.d1e80fa0049c474f9074e278f7023d7a@haskell.org> References: <045.d1e80fa0049c474f9074e278f7023d7a@haskell.org> Message-ID: <060.55e9b34955daf40e08fc5155183135b2@haskell.org> #2659: Add sortOn and other *On functions -------------------------------------+--------------------------------- Reporter: twanvl | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.9 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | -------------------------------------+--------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"44512e3c855d8fb36ab6580f4f97f842ebcf4c6c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="44512e3c855d8fb36ab6580f4f97f842ebcf4c6c" Add Data.List.sortOn function (re #9004 and #2659) `sortOn` sorts a list by comparing the results of a key function applied to each element. `sortOn f` is equivalent to `sortBy . comparing f`, but has the performance advantage of only evaluating `f` once for each element in the input list. Historical note: This was already proposed in 2008 as part of http://www.haskell.org/pipermail/libraries/2008-October/010797.html It was, however, the recent re-attempt http://www.haskell.org/pipermail/libraries/2014-April/022489.html that let `sortOn` make it into base at last. Maybe the other functions mentioned in #2659 might be worth reconsidering as well. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 09:52:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 09:52:06 -0000 Subject: [GHC] #9004: Add sortOn function to Data.List In-Reply-To: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> References: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> Message-ID: <065.d3b5118711ccba3f2a76a3f28847ba47@haskell.org> #9004: Add sortOn function to Data.List -------------------------------+------------------------------------------- Reporter: | Owner: JohnWiegley | Status: patch Type: feature | Milestone: 7.10.1 request | Version: 7.8.2 Priority: normal | Keywords: Component: | Architecture: Unknown/Multiple libraries/base | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"44512e3c855d8fb36ab6580f4f97f842ebcf4c6c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="44512e3c855d8fb36ab6580f4f97f842ebcf4c6c" Add Data.List.sortOn function (re #9004 and #2659) `sortOn` sorts a list by comparing the results of a key function applied to each element. `sortOn f` is equivalent to `sortBy . comparing f`, but has the performance advantage of only evaluating `f` once for each element in the input list. Historical note: This was already proposed in 2008 as part of http://www.haskell.org/pipermail/libraries/2008-October/010797.html It was, however, the recent re-attempt http://www.haskell.org/pipermail/libraries/2014-April/022489.html that let `sortOn` make it into base at last. Maybe the other functions mentioned in #2659 might be worth reconsidering as well. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 09:59:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 09:59:47 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) Message-ID: <048.6de557f445a653925bd78085a02f0022@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This happens in a clean sandbox: {{{ % cabal install -j --enable-library-coverage logict Resolving dependencies... Notice: installing into a sandbox located at /home/feuerbach/tmp/sandboxes/smallcheck-bug/.cabal-sandbox Configuring mtl-2.1.3.1... Building mtl-2.1.3.1... Installed mtl-2.1.3.1 Configuring logict-0.6.0.2... Building logict-0.6.0.2... Failed to install logict-0.6.0.2 Last 10 lines of the build log ( /home/feuerbach/tmp/sandboxes/smallcheck- bug/.cabal-sandbox/logs/logict-0.6.0.2.log ): Configuring logict-0.6.0.2... Building logict-0.6.0.2... Preprocessing library logict-0.6.0.2... [1 of 2] Compiling Control.Monad.Logic.Class ( Control/Monad/Logic/Class.hs, dist/dist-sandbox- cdfcc6f0/build/Control/Monad/Logic/Class.o ) [2 of 2] Compiling Control.Monad.Logic ( Control/Monad/Logic.hs, dist /dist-sandbox-cdfcc6f0/build/Control/Monad/Logic.o ) /usr/bin/ld: dist/dist-sandbox-cdfcc6f0/build/Control/Monad/Logic.dyn_o: relocation R_386_GOTOFF against undefined symbol `_hpc_tickboxes_mtlzm2zi1zi3zi1_ControlziMonadziReaderziClass_hpc' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status cabal: Error: some packages failed to install: logict-0.6.0.2 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 10:19:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 10:19:40 -0000 Subject: [GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) In-Reply-To: <048.6de557f445a653925bd78085a02f0022@haskell.org> References: <048.6de557f445a653925bd78085a02f0022@haskell.org> Message-ID: <063.d6a110506c28af97556b84355ef4fee2@haskell.org> #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) -------------------------------------+------------------------------------ Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Feuerbach): I can reproduce this with both 7.6.3 and 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 12:21:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 12:21:06 -0000 Subject: [GHC] #9008: Data.Function: Add reverse application operator In-Reply-To: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> References: <047.48b22c973b9d333244cb1e3a391943fc@haskell.org> Message-ID: <062.61c01cc2b7c4326cc063469220e6172e@haskell.org> #9008: Data.Function: Add reverse application operator -------------------------------------+------------------------------------ Reporter: bernalex | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 12:21:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 12:21:24 -0000 Subject: [GHC] #9004: Add sortOn function to Data.List In-Reply-To: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> References: <050.adbe9d31164664b0218f403704cd93c1@haskell.org> Message-ID: <065.5701b119b138cbdbb80ffdc0e5d0241b@haskell.org> #9004: Add sortOn function to Data.List -------------------------------+------------------------------------------- Reporter: | Owner: JohnWiegley | Status: closed Type: feature | Milestone: 7.10.1 request | Version: 7.8.2 Priority: normal | Keywords: Component: | Architecture: Unknown/Multiple libraries/base | Difficulty: Easy (less than 1 hour) Resolution: fixed | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 16:08:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 16:08:55 -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.e2d7a642890919b8ba08e0717637c5e4@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.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by George): * keywords: => thread-local state, TLS clang * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 17:29:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 17:29: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.099d7ed62af9db164ccc58fa2dd68739@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.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by carter): there was some recent chatter on the llvm list about adding gcc style global named register support to clang https://groups.google.com/forum/#!msg/llvm-dev/p7GAE_bbDoo/QgJme5LblBkJ and http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-March/071503.html perhaps someone on the ghc team should chime in :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 18:40:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 18:40:13 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.56956815142ea68043b494100a0bcec6@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:"386e874e365e310214b701e6f3cb74b4f75348f4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="386e874e365e310214b701e6f3cb74b4f75348f4" Update Cabal source-repository entries (re #8545) This adapts the source-repository entries to match the new situation of base.git, ghc-prim.git, integer-gmp.git, integer-simple.git, and template-haskell.git being folded into ghc.git Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 18:48:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 18:48:37 -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.73215b6f165c3e226a92382f0773ed89@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.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonmar): It looks like they're lacking good use cases for register variables. I'm not on that list so it's difficult to jump into the middle of the conversation, perhaps someone else could point them to this ticket and/or our use of register variables in the GC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 19:10:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 19:10:10 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.8abe040c7e299cc5bfcba34f8034592f@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by simonmar): So you should be able to repro this manually. I just tried with `-optl- Wl,-z,relro`, but didn't see an error. You can look in `config.log` to see the exact command line that GHC was invoked with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 19:11:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 19:11:55 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.f76d6863e77a3ca63a50dabbd3d6025b@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by simonmar): * owner: => simonmar * priority: normal => high * milestone: => 7.8.3 Comment: Milestoning 7.8.3 since this patch was merged into the 7.8 branch too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 19:27:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 19:27:45 -0000 Subject: [GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) In-Reply-To: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> References: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> Message-ID: <067.217f5a2c5985b9fa6faf3cab49245f32@haskell.org> #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by George): * cc: george.colpitts@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 19:46:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 19:46:22 -0000 Subject: [GHC] #7789: GHCI core dumps when used with VTY In-Reply-To: <049.b36182eedf1c6058b38f280d542dcf30@haskell.org> References: <049.b36182eedf1c6058b38f280d542dcf30@haskell.org> Message-ID: <064.9ecd4dab249dd382e19f4b0079852f29@haskell.org> #7789: GHCI core dumps when used with VTY -------------------------------------+------------------------------------ Reporter: timthelion | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: GHCi | Version: 7.4.2-rc1 Resolution: | Keywords: core dump Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by George): * cc: hvr (added) Comment: On 7.8.2 on Mac OS 10.9.2 compiling and loading this gives: {{{ ghc(57163,0x10f787000) malloc: *** error for object 0x7f9ffa501270: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap: 6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 19:52:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 19:52:10 -0000 Subject: [GHC] #7789: GHCI core dumps when used with VTY In-Reply-To: <049.b36182eedf1c6058b38f280d542dcf30@haskell.org> References: <049.b36182eedf1c6058b38f280d542dcf30@haskell.org> Message-ID: <064.c7f54b7e43b2ededf825289b78ab44de@haskell.org> #7789: GHCI core dumps when used with VTY -------------------------------------+------------------------------------ Reporter: timthelion | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: GHCi | Version: 7.4.2-rc1 Resolution: | Keywords: core dump Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | 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 Sat Apr 19 21:19:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 21:19:43 -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.1a58c03f77fa960aecbb270711e9591a@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.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ezyang): I went ahead and posted mail; hasn't showed up in the archives yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 19 22:42:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Apr 2014 22:42:29 -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.6e14f9317b51c0f54615d6dcf536deca@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.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thoughtpolice): I did not see Edward's reply. I instead posted my own summary for the LLVM people: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/072313.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 20 03:19:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Apr 2014 03:19:21 -0000 Subject: [GHC] #9011: panic - interactiveUI:setBuffering2 In-Reply-To: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> References: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> Message-ID: <059.afe03149ab7546f7e33d5f2410ccf3b8@haskell.org> #9011: panic - interactiveUI:setBuffering2 -------------------------------+---------------------------------- Reporter: irneb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by rwbarton): Is there some context missing here? What have you done exactly and what are you trying to do? What is the relevance of libffi? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 20 03:22:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Apr 2014 03:22:38 -0000 Subject: [GHC] #9013: addWord2# is buggy Message-ID: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> #9013: addWord2# is buggy ------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Looks like its behavior differs between optimization levels: {{{#!haskell {-# LANGUAGE MagicHash, UnboxedTuples #-} import GHC.Prim import GHC.Word big :: Word big = maxBound good = let x = case big of W# w -> w in case plusWord2# x x of (# a, b #) -> (W# a, W# b) main = do putStrLn $ case good of (0, z) -> "Such optimal, much sad" (1, z) -> "No optimization here" }}} I thought I was going crazy! Try the above code with and without -O2 and you'll get different output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 20 03:23:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Apr 2014 03:23:02 -0000 Subject: [GHC] #9013: plusWord2# is buggy (was: addWord2# is buggy) In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.1592efd891e720213f9285f9ebc86ea9@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 20 03:29:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Apr 2014 03:29:29 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.a86de5c5ab64a6656e43595664e7a955@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by pumpkin): I'm attempting to write a fast native Haskell multiprecision natural library, so those *2 variants of the primops are quite handy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 20 03:42:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Apr 2014 03:42:02 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.13d126c8000974c6fa50237e63300f63@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by pumpkin): Reid Barton tracked down the culprit on IRC: https://github.com/ghc/ghc/blob/master/compiler/nativeGen/X86/Ppr.hs#L553 So it looks like: 1. it's not specific to `plusWord2#` 2. it only happens on compile-time literals (so is admittedly pretty rare) 3. it's not always sound to switch an `add` to a `dec` because the latter doesn't affect the carry flag and the former does -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 20 16:31:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Apr 2014 16:31:35 -0000 Subject: [GHC] #9011: panic - interactiveUI:setBuffering2 In-Reply-To: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> References: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> Message-ID: <059.1b7730e60d7eebc6e51016a7f54ed750@haskell.org> #9011: panic - interactiveUI:setBuffering2 -------------------------------+---------------------------------- Reporter: irneb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by irneb): Sorry, it seems I did omit a bit. I'm only starting with Haskell as my next language to learn. So first step: install the needed tools. Did a bit of searching and got various answers ranging from compiling from source to installing from the repo. Anyhoo ... the source idea made for lots of extra manual downloads because these dependencies simply are not available by default. Gave up on that since it simply didn't want to work after about 2 days of trying. Then installed from the repo after adding the universe site to the aps list. Seemed to install properly, but the interactive REPL gives this error message. Then I searched through this forum for the error in question. Found a few threads which stated that installing LibFFI5 solved it and then they were closed. No further info or comments. Then I tried installing this, found that it's not available in the repo, did a search and found that libffi6 superseded libffi5 since Ubuntu 10 (I'm now on 13.10). So installed the new libffi6 and tried again ... no dice, same error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 20 17:37:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Apr 2014 17:37:03 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python Message-ID: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python -------------------------------------------+---------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------+---------------------------- The released Windows 64 tarball available at https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown- mingw32.tar.xz includes the following under `mingw/bin`: * gfortran * gcj * python27.dll * The whole Python 2.7 standard library (`mingw/bin/lib`) These files have probably been included by mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 20 19:39:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Apr 2014 19:39:14 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" In-Reply-To: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> References: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> Message-ID: <063.d38ae6cade4056e928e8e7f6362f0ccf@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by joelteon): This also happens to me on OSX 10.9 with the GHC 7.8.2 binary distribution. Using `-j1` when using cabal prevents the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 20 19:46:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Apr 2014 19:46:55 -0000 Subject: [GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc. Message-ID: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> #9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Moderate (less | bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I'm working on a little REPL and the GHC API seems to supply two functions for evaluating one line, without compiling and evaluating into an `HValue`, which doesn't seem to have an `Outputable` instace: `runStmt` and `runDecls`. As it turns out, I need slightly different code to run on declarations verses statements, so this makes sense, but given a random string from the user, how can I tell the difference? I don't see anything in the documentation about this. I took a look at ghci's source (https://github.com/ghc/ghc/blob/a6f2c852d49313fa8acea2deb3741ab86c6ef995/ghc/InteractiveUI.hs#L862]) and it looks like they just peek at the first word of the input, and that may be correct and sufficient, but impossible to verify without looking at Haskell's grammar. But even if I did verify it, that doesn't make explicit the difference between what `runDecls` and `runStmt` will accept. For a contrived example, consider if GHC implemented a feature that allowed for a new type of decl. It might be enabled by a language extension which means that testing whether a string is a statement or declaration cannot be done purely as we have to check the dynflags. Furthermore, the client may not be aware of the extension and thus send the input to `runStmt` instead. It would seem to me that requiring the user to manually parse the input violates separation of concerns since truly GHC knows best what source GHC will accept. The user should not have to examine the input except for if they need to modify or interpret it as something other than Haskell source code. The GHC API should either document an example function for differentiating declarations from statements (and even import statements), supply one itself, or supply several along the lines of `isDecl, isStmt, isImport :: String -> Bool`. This would improve ease-of-use by making client code more obvious and correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 20 22:05:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Apr 2014 22:05:58 -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.6a311740af1ea810bc200eacdf766fba@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.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thoughtpolice): For those who didn't follow the list: - Mark Seaborn, a !Chromium/NaCl engineer, stated that they have this exact same problem in Native Client on 64bit OS X. In particular, they came up with the same solution I did essentially: inline the fast path of `pthread_{get,set}specific`. Their code is more robust than my patch however, as it's actually paranoid enough to check the machine code and bail otherwise: https://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/trusted/service_runtime/arch/x86_64/nacl_tls_64.c?revision=11149 I think this is probably the best approach at the moment - Renato Golin, the proposer of the initial change, updated me to say that their updated proposal does include register variables for general purpose registers (GPRs), but it's only one part of the overall set of changes, which will take more time (their particular motivation now seems to be as a principled approach to defining `__builtin_return_address` and friends at the moment). However, they understand that proposal doesn't accommodate our design, and would like us to give more feedback as they evolve the work to support true register variables. So, in the long haul, I think things will get better here. In the mean time, I think this is a signal that we should go ahead and jump on the fast-path-inline change I spoke of in comment 13. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 03:39:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 03:39:41 -0000 Subject: [GHC] #9016: Add System.Exit.die Message-ID: <050.e4566798430f089e73482601b9abc89f@haskell.org> #9016: Add System.Exit.die ------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- (as per the proposal/discussion on haskell-libraries, I just posted a summary that "awaits moderator approval") -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 05:36:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 05:36:00 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.b0fcd0d9cdf4e7cb9c3b5dac08874d6e@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by supki): * cc: matvey.aksenov+ghctrac@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 08:20:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 08:20:04 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.d30ce01d6a210afd092002399d0f8648@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): The offending code you point to is {{{ pprInstr (ADD size (OpImm (ImmInt (-1))) dst) = pprSizeOp (sLit "dec") size dst }}} Interestingly, this line dates back at least before 2005; see `7d61cb61` for example. It's surprising to me that * it's the ''pretty-printer'' that is doing some peephole-style optimisations * there is no case for optimising `SUB src 1` to `dec src`, or `SUB src (-1)`. Moreover, it's clearly too late in the pipeline, because by this point the difference between `plusWord#` and `plusWord2#` has disappeared. So fixing the problem by deleting these two lines would lose a perfectly good optimisation for `plusWord#`. Surely it'd be better for some earlier phase to optimise `(plusWord# x (-1))` to `(minusWord# x 1)`; but of course not to do so for `plusWord2#` since (as you say) the carry is affected differently. Moreover, the transformation would then be platform-independent, rather than per- platform. Although, now I think about it, the ''reason'' for doing the optimisation is to expose the possibility for subsequent, platform- specific `inc/dec` optimisations. Maybe that would be OK if documented. Or maybe we could simply do it in passage from Cmm to native code (when we know what primop is being used) rather than in the pretty printer? It looks to me as if `plusWord2#` is the primop `WordAdd2Op`, which in turn is translated to the `CallishMachOp` called `MO_Add2`, which in turn is translated (on X86) to `ADC`. So now I'm confused how the pretty- printer's optimisation of `ADD` affected this program. Would someone like to dig a little deeper and propose a fix (other than the sticking-plaster of deleting above two lines)? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 08:37:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 08:37:57 -0000 Subject: [GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc. In-Reply-To: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> References: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> Message-ID: <069.886a3f621c8e762f8ac750492bbdf37e@haskell.org> #9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Moderate (less bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): I agree. Would you like to submit a patch, implementing (and documenting) the functions you describe; and then calling them from the (ill-named) `InteractiveUI.runStmt`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 09:58:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 09:58:03 -0000 Subject: [GHC] #9017: Confusing error message with PolyKinds Message-ID: <044.615421c3033985dd14fef72264fc6cea@haskell.org> #9017: Confusing error message with PolyKinds ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following example code: {{{ import Control.Arrow foo :: a b (m b) foo = arr return }}} if we typecheck this we rightly get two errors about missing instances (Arrow a, Monad m). However, if we enable `PolyKinds` we get the following error message: {{{ T.hs:4:7: Kind incompatibility when matching types: a0 :: * -> * -> * a :: k1 -> k -> * Expected type: a b (m b) Actual type: a0 b0 (m0 b0) Relevant bindings include foo :: a b (m b) (bound at T.hs:4:1) In the expression: arr return In an equation for ?foo?: foo = arr return }}} I can ''sort of'' see where this is coming from if I think really hard :), so perhaps it's not a bug per se, but it's definitely confusing; and it's a pity that a type error (forgotten type qualifier) is reported as a kind error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 10:59:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 10:59:32 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.b002e72fdf3a50f5fd53a48c3b90ada1@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): For the mean-time, here's the [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/20872 libraries@ thread] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 11:02:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 11:02:08 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.b3ead20a2f5650e2db910cc7b9647f19@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Simon, would you mind adding an empty line + `/Since: 4.7.1.0/` to the haddock string, as well as adding a short [[GhcFile(libraries/base/changelog.md)]] entry to the patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 11:04:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 11:04:10 -0000 Subject: [GHC] #9018: GHC suppresses too much kind information Message-ID: <046.c3a6990365759bc20aaf2b78e8937436@haskell.org> #9018: GHC suppresses too much kind information ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC tends to hide important kind polymorphism in error messages and in GHCi. (I came across this when looking at #9017.) For example, try this: {{{ bash$ cat Test.hs {-# LANGUAGE PolyKinds #-} module Test where foo :: m a foo = foo bash$ ghci Test.hs ghci> :t foo foo :: m a ghci> :i foo foo :: m a bash$ ghci Test.hs -XPolyKinds ghci> :t foo foo :: m a ghci> :i foo goo :: m a bash$ ghci Test.hs -fprint-explicit-foralls -fprint-explicit-kinds ghci> :t foo foo :: foo :: forall (m :: * -> *) d. m d ghci> :i foo foo :: forall (k :: BOX) (m :: k -> *) (d :: k). m d bash$ ghci Test.hs -XPolyKinds -fprint-explicit-foralls -fprint-explicit- kinds ghci> :t foo foo :: forall (k :: BOX) (m :: k -> *) (d :: k). m d ghci> :i foo foo :: forall (k :: BOX) (m :: k -> *) (d :: k). m d }}} Pretty confusing eh? * Without `-fprint-explicit-foralls -fprint-explicit-kinds` you don't see the kinds on the types at all. * Without `-XPolyKinds` in GHCi, when you say `:t foo` you are asking for the type of the expression `foo` (it could be an arbitrary expression). So `foo` is instantiated and then re-generalised; but without `-XPolyKinds` we don't get a poly-kinded type. Hence the difference in what is printed by `:type` and `:info`. Here's a proposal: even without `-fprint-explicit-foralls`, we should print any foralls that bind a type variable whose kind includes a kind variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 11:11:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 11:11:29 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.ab0c741e3bb57d980bd35f04d2a7a2cc@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * cc: ekmett (added) * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 11:16:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 11:16:29 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.c8e39c5a722ae3ab83c5ddfb6aa5ae56@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by SimonHengel): Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 11:18:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 11:18:05 -0000 Subject: [GHC] #9018: GHC suppresses too much kind information In-Reply-To: <046.c3a6990365759bc20aaf2b78e8937436@haskell.org> References: <046.c3a6990365759bc20aaf2b78e8937436@haskell.org> Message-ID: <061.6de4d61d3708d1bebc7db2973463b5d8@haskell.org> #9018: GHC suppresses too much kind information -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): +1 from me. I lived without a .ghci file until I experienced pain from this particular issue. Now, I have {{{ :seti -XPolyKinds :set -fprint-explicit-foralls :set -fprint-explicit-kinds }}} among other options. Perhaps it might also be nice to inform the user to use `-fprint-explicit- kinds` in an error message if some heuristics (don't know what, at the moment) indicate that it might be helpful. I feel like I've answered several invalid bug reports because of quite legitimately confusing error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 11:23:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 11:23:05 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.06843daea077c58b96d2d2000ef53b41@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:5 SimonHengel]: > Like so, or should the changelog entry be more verbose? It's fine, I'll take it from here, thanks :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 11:43:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 11:43:32 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.b4df0333f74f6e3f14412ccf71f2951c@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): Well, I've found the source of this bug. It turned out, windows does not like 64-bit offsets, perhaps, this is PE32+'s painful legacy. Here is the difference between segfaulting and working (manually created) code: {{{ --- T8947.s 2014-04-21 14:02:47.240488500 +0400 +++ T8947m.s 2014-04-21 15:22:41.951320900 +0400 @@ -85,7 +85,8 @@ .globl T8947_t1_info_itable # @T8947_t1_info_itable .align 8 T8947_t1_info_itable: - .quad S1i6_srt-T8947_t1_info + .long S1i6_srt-T8947_t1_info + .long 0 .quad 4294967299 # 0x100000003 .quad 0 # 0x0 .quad 64424509455 # 0xf0000000f @@ -145,7 +146,8 @@ .text .align 8 # @c1hV_info_itable c1hV_info_itable: - .quad S1i6_srt-c1hV_info + .long S1i6_srt-c1hV_info + .long 0 .quad 0 # 0x0 .quad 47244640288 # 0xb00000020 @@ -167,7 +169,8 @@ .globl T8947_t8947_info_itable # @T8947_t8947_info_itable .align 8 T8947_t8947_info_itable: - .quad (S1i6_srt-T8947_t8947_info)+16 + .long (S1i6_srt-T8947_t8947_info)+16 + .long 0 .quad 4294967299 # 0x100000003 .quad 0 # 0x0 .quad 4294967311 # 0x10000000f }}} Bad data are generated by the following llvm code: {{{ ... @T8947_t1_info_itable = constant %T8947_t1_entry_struct<{i64 add (i64 sub (i64 ptrtoint (i8* @S1i6_srt$alias to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @T8947_t1_info to i64)),i64 0), i64 4294967299, i64 0, i64 64424509455}>, section "X98A__STRIP,__me3", align 8 ... @c1hV_info_itable = internal constant %c1hV_entry_struct<{i64 add (i64 sub (i64 ptrtoint (i8* @S1i6_srt$alias to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @c1hV_info to i64)),i64 0), i64 0, i64 47244640288}>, section "X98A__STRIP,__me5", align 8 ... @T8947_t8947_info_itable = constant %T8947_t8947_entry_struct<{i64 add (i64 sub (i64 ptrtoint (i8* @S1i6_srt$alias to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @T8947_t8947_info to i64)),i64 16), i64 4294967299, i64 0, i64 4294967311}>, section "X98A__STRIP,__me7", align 8 ... }}} But don't quite understand where in the GHC code shall I intervene precisely to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 11:46:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 11:46:06 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.11cc63b856bc04c290c6e2fb52648b59@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Ok, this needs `Cabal` to be tweaked as well, due to an overly optimistic unqualified import in `Cabal` :-) {{{ libraries/Cabal/Cabal/Distribution/Simple.hs:412:7: Ambiguous occurrence ?die? It could refer to either ?Distribution.Simple.Utils.die?, imported from ?Distribution.Simple.Utils? at libraries/Cabal/Cabal/Distribution/Simple.hs:92:11-13 or ?System.Exit.die?, imported from ?System.Exit? at libraries/Cabal/Cabal/Distribution/Simple.hs:108:1-18 libraries/Cabal/Cabal/Distribution/Simple.hs:417:7: Ambiguous occurrence ?die? It could refer to either ?Distribution.Simple.Utils.die?, imported from ?Distribution.Simple.Utils? at libraries/Cabal/Cabal/Distribution/Simple.hs:92:11-13 or ?System.Exit.die?, imported from ?System.Exit? at libraries/Cabal/Cabal/Distribution/Simple.hs:108:1-18 libraries/Cabal/Cabal/Distribution/Simple.hs:591:27: Ambiguous occurrence ?die? It could refer to either ?Distribution.Simple.Utils.die?, imported from ?Distribution.Simple.Utils? at libraries/Cabal/Cabal/Distribution/Simple.hs:92:11-13 or ?System.Exit.die?, imported from ?System.Exit? at libraries/Cabal/Cabal/Distribution/Simple.hs:108:1-18 libraries/Cabal/Cabal/Distribution/Simple.hs:641:36: Ambiguous occurrence ?die? It could refer to either ?Distribution.Simple.Utils.die?, imported from ?Distribution.Simple.Utils? at libraries/Cabal/Cabal/Distribution/Simple.hs:92:11-13 or ?System.Exit.die?, imported from ?System.Exit? at libraries/Cabal/Cabal/Distribution/Simple.hs:108:1-18 }}} I've pushed the commit to a `wip/`-branch for now at https://github.com/ghc/ghc/commit/c4ea79c71ad01287bfbdaafa78bdf195988411e2 until this is resolved in `Cabal` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 11:50:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 11:50:37 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception In-Reply-To: <044.4c21331b0c5897214741257d5027da6d@haskell.org> References: <044.4c21331b0c5897214741257d5027da6d@haskell.org> Message-ID: <059.d5678c7693c4a381d68e47c0c9228423@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: th/T8987 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by Yuras): * testcase: => th/T8987 Comment: Should it be marked as closed or merge? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 11:52:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 11:52:02 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.258b72de9356b15e064b802c07ec855a@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by bernalex): * cc: ekmett (added) * status: new => patch Comment: I added my patches for this here per SPJ's suggestion. The signum patch does not work. I do not know why. It must be due to GHC internals, because the function itself is fine as may be verified by copying {{{ signumFix x | x == 0.0 = x | isNaN x = x | x > 0.0 = 1 | otherwise = negate 1 }}} into a file signumfix.hs and :l signumfix.hs into GHCi. signumFix (-0.0 :: Float) will now return -0.0, where Prelude.signum returns 0.0 with the same argument. Here is a core dump of me invoking my Prelude.signum after building GHC/GHCi with my patches: {{{ Prelude> abs (-0.0 :: Float) ==================== Simplified expression ==================== let { it_aqt :: GHC.Types.Float [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] it_aqt = GHC.Num.abs @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Num.negate @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aqt) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_aqt `cast` (UnivCo representational GHC.Types.Float () :: GHC.Types.Float ~# ())) (GHC.Types.[] @ ()))) 0.0 Prelude> signum (-0.0 :: Float) ==================== Simplified expression ==================== let { it_aKQ :: GHC.Types.Float [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] it_aKQ = GHC.Num.signum @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Num.negate @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aKQ) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_aKQ `cast` (UnivCo representational GHC.Types.Float () :: GHC.Types.Float ~# ())) (GHC.Types.[] @ ()))) 0.0 }}} Please note that the abs patch works well and is likely ready to go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 12:03:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 12:03:42 -0000 Subject: [GHC] #8947: Depending on hint/ghc API fixes the binary version I can use In-Reply-To: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> References: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> Message-ID: <057.c0c38b3835977f4a28734d311c782004@haskell.org> #8947: Depending on hint/ghc API fixes the binary version I can use ----------------------------------------------+---------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 12:10:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 12:10:36 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.cd5eb568b67d11353aff2b23d2156956@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 13:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 13:14:33 -0000 Subject: [GHC] #8987: TH: panic in reportWarning when the message throws an exception In-Reply-To: <044.4c21331b0c5897214741257d5027da6d@haskell.org> References: <044.4c21331b0c5897214741257d5027da6d@haskell.org> Message-ID: <059.bab1e01a51858143cbdd707b8e5ef9d3@haskell.org> #8987: TH: panic in reportWarning when the message throws an exception ---------------------------------------+----------------------------------- Reporter: Yuras | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: th/T8987 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 15:18:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 15:18:37 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.15ac4f5174f21d42df8752f4ca7a090b@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"e2b14c70c800363db5ccb5c3032eed8b9d7d3747/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e2b14c70c800363db5ccb5c3032eed8b9d7d3747" Use import list to hide new System.Exit.die Soon, System.Exit will export the new `die` (see #9016) which would clash with Cabal's own `die` implementation. This commit provides forward- compatiblity. This also updates the Cabal submodule which requires a similiar fix. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 15:18:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 15:18:38 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.423b064563c587fca2c3e86c918381a2@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"77ea2eb0ab36d1a610269f6737b509b6f6a376fa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="77ea2eb0ab36d1a610269f6737b509b6f6a376fa" Add System.Exit.die (re #9016) The original proposal discussion can be found at http://thread.gmane.org/gmane.comp.lang.haskell.libraries/20872 Note this also updates the Haddock submodule to remove Hadock's local `die` implementation. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 17:03:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 17:03:23 -0000 Subject: [GHC] #9019: Ambiguity checker overeager on "ambiguous" kind variables Message-ID: <047.ee327e008dbe14018d786d30dd9de67e@haskell.org> #9019: Ambiguity checker overeager on "ambiguous" kind variables ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following shenanigans: {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies, ExistentialQuantification #-} module Bug where import Data.Proxy data TyFun :: * -> * -> * type family Apply (f :: TyFun k1 k2 -> *) (x :: k1) :: k2 data LeftSym0 l = forall arg. Apply LeftSym0 arg ~ Left arg => LS0KI (Proxy arg) }}} Compiling (with `-fprint-explicit-foralls -fprint-explicit-kinds`) gives this error message: {{{ /Users/rae/temp/Bug.hs:12:3: Could not deduce ((~) (Either k3 k0) (Apply (Either k3 k0) k3 (LeftSym0 k0 k3) arg) ('Left k3 k0 arg)) from the context ((~) (Either k3 k2) (Apply (Either k3 k2) k3 (LeftSym0 k2 k3) arg) ('Left k3 k2 arg)) bound by the type of the constructor ?LS0KI?: (~) (Either k3 k2) (Apply (Either k3 k2) k3 (LeftSym0 k2 k3) arg) ('Left k3 k2 arg) => Proxy k3 arg -> LeftSym0 k k1 l at /Users/rae/temp/Bug.hs:12:3 The type variable ?k0? is ambiguous In the ambiguity check for: forall (k :: BOX) (k1 :: BOX) (l :: TyFun k1 (Either k1 k)) (k2 :: BOX) (k3 :: BOX) (arg :: k3). (~) (Either k3 k2) (Apply (Either k3 k2) k3 (LeftSym0 k2 k3) arg) ('Left k3 k2 arg) => Proxy k3 arg -> LeftSym0 k k1 l To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the definition of data constructor ?LS0KI? In the data declaration for ?LeftSym0? }}} The file compiles without incident with `-XAllowAmbiguousTypes`. What's interesting is that, then, the following separate module compiles: {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies #-} module B2 where import Bug import Data.Proxy type instance Apply LeftSym0 x = Left x foo = LS0KI Proxy }}} It seems that `LS0KI`'s type was not so ambiguous after all. I would want to reduce the test case, but it's hard to figure out what GHC is thinking here, as it reports an ambiguous `k0` variable, which does not appear in the type it is examining. A few rather naive attempts to reduce failed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 18:13:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 18:13:54 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.b313639f4d661800ca46878630db0e69@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): I think that things are pretty much explained in [http://git.haskell.org/ghc.git/blob/HEAD:/compiler/nativeGen/X86/Ppr.hs#l462 native codegen code]. But AFAIUI, when the relevant LLVM code was written, non-Windows binutils were already improved and that was not taken into account (Windows binutils are not fixable anyway in general). Then it looks `pprInfoTable` [http://git.haskell.org/ghc.git/blob/HEAD:/compiler/llvmGen/LlvmCodeGen/Ppr.hs#l111 code] is the point we could try to rewrite things at. Unfortunately, at this point we are forced to "reverse engineer" what was [http://git.haskell.org/ghc.git/blob/HEAD:/compiler/llvmGen/LlvmCodeGen/Data.hs#l116 done before, and it is tempting to intervene here], but it seems we can't intervene at this early stage because this can break things in contexts other than `pprInfoTable`'s one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 18:36:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 18:36:45 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.df31c1a9f95c328aabd37b410490de8b@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Lemming): You can rewrite the constraint {{{ (Functor (PF a), Regular a) }}} to {{{ (PF a ~ pfa, Functor pfa, Regular a) }}} and then it is no longer a FlexibleContext. However, this trick does not work in superclasses since you must only use class parameters there and you cannot introduce new variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 18:56:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 18:56:04 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.fcf5c9479453d0bfed46442d77232fe4@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"bcd989d13072a189b49d9393b0d4b1bbaede9d36/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bcd989d13072a189b49d9393b0d4b1bbaede9d36" Generalise type of recently added System.Exit.die This is a follow-up to 77ea2eb0ab36d1a (re #9016) which added `die` with a return type of `IO ()` even though all other functions in System.Exit have the more general return type `IO a`. It is assumed this was an oversight in the original proposal. Acked-by: Edward Kmett Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 18:58:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 18:58:09 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.d6b9581ca6014fe8eca175e28bb9a3ed@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by rwbarton): If we're doing this, can we also enable !FlexibleContexts by default? Is there any good reason not to? (Can it break any working code?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 21:42:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 21:42:26 -0000 Subject: [GHC] #8253: example "Core syntax" is ancient In-Reply-To: <047.c3b31fabaa8a2840d3e512d5592d8b22@haskell.org> References: <047.c3b31fabaa8a2840d3e512d5592d8b22@haskell.org> Message-ID: <062.5b35e2212c954f3c662f9c950bfb9e53@haskell.org> #8253: example "Core syntax" is ancient -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: 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: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by afleck): Wow, that's very different, the same comments don't even apply. Is it necessary to re-comment the code? I've attached a log of the output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 21 21:51:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Apr 2014 21:51:48 -0000 Subject: [GHC] #8141: Liberalising IncoherentInstances In-Reply-To: <046.35fbeee3a815352f8d7c3d61f38385ae@haskell.org> References: <046.35fbeee3a815352f8d7c3d61f38385ae@haskell.org> Message-ID: <061.79e1b029dd1c3865552a5a25c4fc7c13@haskell.org> #8141: Liberalising IncoherentInstances -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): for posterity, a working link to the associated cafe discussion is http://www.haskell.org/pipermail/glasgow-haskell- users/2013-July/024131.html (the old links didn't work) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 02:32:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 02:32:25 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.75fd3e3d9b92023579a365d16ab9d3a5@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by juhpetersen): * cc: juhp@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 04:40:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 04:40:23 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.429ef76ad9911df76ba3938df1349f31@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Comment (by Austin Seipp ): In [changeset:"5a31f231eebfb8140f9b519b166094d9d4fc2d79/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5a31f231eebfb8140f9b519b166094d9d4fc2d79" Be less untruthful about the prototypes of external functions GHC's generated C code uses dummy prototypes for foreign imports. At the moment these all claim to be (void), i.e. functions of zero arguments. On most platforms this doesn't matter very much: calls to these functions put the parameters in the usual places anyway, and (with the exception of varargs) things just work. However, the ELFv2 ABI on ppc64 optimises stack allocation (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01149.html): a call to a function that has a prototype, is not varargs, and receives all parameters in registers rather than on the stack does not require the caller to allocate an argument save area. The incorrect prototypes cause GCC to believe that all functions declared this way can be called without an argument save area, but if the callee has sufficiently many arguments then it will expect that area to be present, and will thus corrupt the caller's stack. This happens in particular with calls to runInteractiveProcess in libraries/process/cbits/runProcess.c. The simplest fix appears to be to declare these external functions with an unspecified argument list rather than a void argument list. This is no worse for platforms that don't care either way, and allows a successful bootstrap of GHC 7.8 on little-endian Linux ppc64 (which uses the ELFv2 ABI). Fixes #8965 Signed-off-by: Colin Watson Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 04:41:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 04:41:59 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.07ec9971891ce4882458fc4f0507a089@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7623, 8664 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: patch => closed * version: 7.6.3 => * resolution: => fixed * related: => 7623, 8664 * blockedby: 7623, 8664 => Comment: This has been merged in c29bf984dd20431cd4344e8a5c444d7a5be08389 - thank you Colin! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 04:42:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 04:42:25 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.7950fd3058eaa78cc4bfdc746d375532@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Changes (by thoughtpolice): * status: patch => merge Comment: Merged, thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 04:42:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 04:42:50 -0000 Subject: [GHC] #8861: Use commas to separate thousands when printing memory stats In-Reply-To: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> References: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> Message-ID: <061.cba040386c6ca4f91624c264d394848d@haskell.org> #8861: Use commas to separate thousands when printing memory stats -------------------------------+------------------------------------------- Reporter: ErlendH | Owner: Type: feature | Status: closed request | Milestone: Priority: lowest | Version: 7.6.3 Component: GHCi | 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: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 04:43:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 04:43:11 -0000 Subject: [GHC] #8940: "make help" fails In-Reply-To: <043.56b6e22a9950cbc1198cdc30c7e96b87@haskell.org> References: <043.56b6e22a9950cbc1198cdc30c7e96b87@haskell.org> Message-ID: <058.29ae899bced35df21e115050b199515b@haskell.org> #8940: "make help" fails -------------------------------------+------------------------------------ Reporter: uznx | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build 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: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 04:44:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 04:44:06 -0000 Subject: [GHC] #8458: T5435_dyn_asm fails on x86_64 Linux In-Reply-To: <048.6da04b00f79d78287d314ac7b472c3f4@haskell.org> References: <048.6da04b00f79d78287d314ac7b472c3f4@haskell.org> Message-ID: <063.c093d7ea1248393d88b018cdbb6ae5bc@haskell.org> #8458: T5435_dyn_asm fails on x86_64 Linux ------------------------------------------------+-------------------------- Reporter: jstolarek | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: I'm not particularly inclined to merge this, FWIW, so I'm marking as closed unless someone else feels differently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:17:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:17:10 -0000 Subject: [GHC] #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory In-Reply-To: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> References: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> Message-ID: <063.b540f6b6c80960a2c60fc6fb39213ede@haskell.org> #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory ---------------------------------------+----------------------------------- Reporter: wmarshall | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:17:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:17:31 -0000 Subject: [GHC] #8932: Panic with TemplateHaskell and duplicate indentifiers In-Reply-To: <048.cd6ad88ea09e222679040103b1a3c25b@haskell.org> References: <048.cd6ad88ea09e222679040103b1a3c25b@haskell.org> Message-ID: <063.22204c8804fbb2c0af231229853c998c@haskell.org> #8932: Panic with TemplateHaskell and duplicate indentifiers ---------------------------------------+----------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: th/T8932 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:18:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:18:24 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.4e62d3c381fcdbda8ca5515e6a38f655@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:19:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:19:19 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.ab602f838c6c7680c4bef6b582096c56@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.3 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc2 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: simplCore/should_compile/T8848, T8848a | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: This didn't properly merge to the 7.8 branch - I think some of Joachim's work (some which probably should not be merged) caused a conflict, and I haven't traced down exactly which commits those are. As it is, I'm inclined to not merge this, then. I'm marking as fixed - please let me know if someone disagrees. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:26:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:26:04 -0000 Subject: [GHC] #8966: Pattern synonyms and kind-polymorphism In-Reply-To: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> References: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> Message-ID: <062.9438777c6b817da2796f011e7da95643@haskell.org> #8966: Pattern synonyms and kind-polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: simonpj Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: patsyn/T8966 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by thoughtpolice): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:26:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:26:12 -0000 Subject: [GHC] #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism In-Reply-To: <047.369cd023f51a0cded951f791a8f64164@haskell.org> References: <047.369cd023f51a0cded951f791a8f64164@haskell.org> Message-ID: <062.8d109df47fef3c1665b517b5ee009c1e@haskell.org> #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: polykinds/T8985 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by thoughtpolice): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:26:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:26:53 -0000 Subject: [GHC] #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory In-Reply-To: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> References: <048.2d7f3fd6d82dfa87e6a726166d2648da@haskell.org> Message-ID: <063.67951082de886943a01ae6ee227206c7@haskell.org> #8641: ghc with -odir and -prof (or any stub file) does not create the specified output directory ---------------------------------------+----------------------------------- Reporter: wmarshall | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.9 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): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:27:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:27:06 -0000 Subject: [GHC] #8932: Panic with TemplateHaskell and duplicate indentifiers In-Reply-To: <048.cd6ad88ea09e222679040103b1a3c25b@haskell.org> References: <048.cd6ad88ea09e222679040103b1a3c25b@haskell.org> Message-ID: <063.34ef3fd25ba464069220cc4286d0da22@haskell.org> #8932: Panic with TemplateHaskell and duplicate indentifiers ---------------------------------------+----------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: th/T8932 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:36:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:36:26 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.efe0324d0687882ee79acf021789cf57@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonpj): Lemming has a good point, I guess. `Functor (PF a)` is currently rejected without `FlexibleContexts` but I guess it could instead be accepted. Moreover even in H98 the context `Functor (f a)` is accepted, so you could argue that with `TypeFamilies` we should accept `Functor (PF a)`. I can't get terribly excited about this decision; but I can see the logic, and I'll gladly change the current behaviour if there is support for doing so. (This would affect both inferred and declared types, of course.) rwbarton: GHC does Haskell 2010 by default. That's how we choose what to enable by default, otherwise we'd argue about "should X be on by default" for ages! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:38:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:38:11 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.2fb46eb049469b2184eb2334c4f7545e@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | 7.10.1 Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 7.8.1-rc2 Test Case: | Keywords: simplCore/should_compile/T8848, T8848a | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * milestone: 7.8.3 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 06:44:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 06:44:05 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.823a938c9bb1684b7c46840394cefc9a@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by simonpj): See [http://www.haskell.org/pipermail/libraries/2014-April/022730.html this libraries-list thread] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:02:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:02:27 -0000 Subject: [GHC] #9019: Ambiguity checker overeager on "ambiguous" kind variables In-Reply-To: <047.ee327e008dbe14018d786d30dd9de67e@haskell.org> References: <047.ee327e008dbe14018d786d30dd9de67e@haskell.org> Message-ID: <062.1645ca04f46488b467314b962e33d702@haskell.org> #9019: Ambiguity checker overeager on "ambiguous" kind variables -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Sure it's ambiguous! Try {{{ lsoki :: Apply LeftSym0 arg ~ Left arg => Proxy arg -> LeftSym0 l lsoki = LSOKI }}} and you get the exact same error message. "Ambiguous" does not mean "can never under any circumstances be called". Here's a simpler example: {{{ class C (x :: Maybe a) data LeftSym0 where LSOKI :: C Nothing => LeftSym0 }}} This gives {{{ T9019.hs:9:3: Could not deduce (C k0 ('Nothing k0)) arising from the ambiguity check for the type of the constructor ?LSOKI? from the context (C k ('Nothing k)) bound by the type of the constructor ?LSOKI?: C k ('Nothing k) => LeftSym0 at T9019.hs:9:3 The type variable ?k0? is ambiguous In the ambiguity check for: forall (k :: BOX). C k ('Nothing k) => LeftSym0 }}} And indeed, there is nothing to resolve that ambiguous 'k', just as there wasn't in the previous example. So this looks right to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:17:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:17:28 -0000 Subject: [GHC] #8861: Use commas to separate thousands when printing memory stats In-Reply-To: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> References: <046.e21545148e081f7f07857eb0bed3fa24@haskell.org> Message-ID: <061.fe803440ba0cbcdcbefc7d73c695d9ef@haskell.org> #8861: Use commas to separate thousands when printing memory stats -------------------------------+------------------------------------------- Reporter: ErlendH | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: lowest | Version: 7.6.3 Component: GHCi | 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 hvr): * milestone: => 7.10.1 Comment: btw, this went in as 9ca17f8850aeaf1fd2109532338da2ffc0e8be1b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:27:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:27:36 -0000 Subject: [GHC] #8966: Pattern synonyms and kind-polymorphism In-Reply-To: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> References: <047.115ac018b402a89537649fa13ab8f25d@haskell.org> Message-ID: <062.fc147722c19c07e99004f3246cb13400@haskell.org> #8966: Pattern synonyms and kind-polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: Resolution: fixed | 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: patsyn/T8966 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:27:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:27:43 -0000 Subject: [GHC] #8954: Reifying the nullary unboxed tuple is broken In-Reply-To: <047.db7c3dce80c2c09f762efbd3c1842bf1@haskell.org> References: <047.db7c3dce80c2c09f762efbd3c1842bf1@haskell.org> Message-ID: <062.c3ba4ea6e2e549bf277c277598e85898@haskell.org> #8954: Reifying the nullary unboxed tuple is broken -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.8.3 Component: Template Haskell | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: th/T8954 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:27:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:27:49 -0000 Subject: [GHC] #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism In-Reply-To: <047.369cd023f51a0cded951f791a8f64164@haskell.org> References: <047.369cd023f51a0cded951f791a8f64164@haskell.org> Message-ID: <062.02aaa4ea28974133d30ff4ee02e7874f@haskell.org> #8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphism ----------------------------------------------+---------------------------- Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: polykinds/T8985 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:29:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:29:45 -0000 Subject: [GHC] #6017: Reading ./.ghci files raises security issues In-Reply-To: <046.4c80215545a1055cdc72cec5a74c2a85@haskell.org> References: <046.4c80215545a1055cdc72cec5a74c2a85@haskell.org> Message-ID: <061.f3095438c58f8c29c837de987ee06d93@haskell.org> #6017: Reading ./.ghci files raises security issues -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: closed Priority: high | Milestone: 7.8.3 Component: GHCi | Version: 7.4.1 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): * cc: hvr (added) * status: new => closed * resolution: => fixed Comment: This is now fixed, and also merged to the 7.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:30:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:30:29 -0000 Subject: [GHC] #6017: Reading ./.ghci files raises security issues In-Reply-To: <046.4c80215545a1055cdc72cec5a74c2a85@haskell.org> References: <046.4c80215545a1055cdc72cec5a74c2a85@haskell.org> Message-ID: <061.23b72b16478d78720b6527b9fbac4ac2@haskell.org> #6017: Reading ./.ghci files raises security issues -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.3 Component: GHCi | Version: 7.4.1 Resolution: | 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: closed => new * resolution: fixed => Comment: Whoops, sorry. I misread the intention of the ticket, here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:33:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:33:07 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program Message-ID: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> #9020: Massive blowup of code size on trivial program ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The test `simplCore/should_compile/simpl015` was leading to massive compile times. This is weird: it looks like: {{{ main = do { return () ; return () ... hundreds more times ... ; return () } }}} It turns out that the cause was over-eager eta-expansion. Each `return ()` gives a top-level PAP thus {{{ lvl17 :: IO () lvl17 = returnIO () }}} But these definitions are then eta-expanded, thus: {{{ lvl17 = ((\eta. returnIO () |> sym g) eta) |> g where g :: State# RealWorld -> (# State# RealWorld, () #) ~ IO () }}} Now in general it makes sense to eta-expand through newtypes (as is done here), because it exposes more lambadas. But it really doesn't make sense to eta-expand a PAP like this. Fortunately the fix is easy: use `exprArity` rather than `manifestArity` in `SimplUtils.tryEtaExpandRhs`. The effect on `simpl015` is dramatic: compiler allocation drops from 6.6G to 812M; and residency drops from 1.8G to 45M. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:34:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:34:25 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.74a939b79917a3ea8ce9ac1c7c48837c@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | 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 thoughtpolice): * milestone: => 7.8.3 Comment: I believe this should now be fixed by 396648eebaa1144d4d1f5326db716e8130f73732 - furthermore, this commit has been merged into the 7.8 branch. Can anyone test this please? I have not been able to reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:51:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:51:24 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.e935822b0278d6e0658233fd9db86d9d@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): I've decided that intervening at [http://git.haskell.org/ghc.git/blob/HEAD:/compiler/llvmGen/LlvmCodeGen/Data.hs#l116 `genStaticLit (CmmLabelDiffOff l1 l2 off)`] is safe and have rewritten the code to generate 32-bit arithmetic and pointer conversion, but it turned out LLVM generates unsuitable code for `ptrtoint ... to i32` applied to 64-bit pointer. For example, if {{{ @T8947_t1_info_itable = constant %T8947_t1_entry_struct<{i64 add (i64 sub (i64 ptrtoint (i8* @S1fL_srt$alias to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @T8947_t1_info to i64)),i64 0), i64 4294967299, i64 0, i64 64424509455}>, section "X98A__STRIP,__me3", align 8 }}} gets rewritten to {{{ @T8947_t1_info_itable = constant %T8947_t1_entry_struct<{i32 add (i32 sub (i32 ptrtoint (i8* @S1i6_srt$alias to i32),i32 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @T8947_t1_info to i32)),i32 0), i32 0, i64 4294967299, i64 0, i64 64424509455}>, section "X98A__STRIP,__me3", align 8 }}} LLVM instead of {{{ T8947_t1_info_itable: .quad S1i6_srt-T8947_t1_info }}} generates (assembler spits {{{Error: invalid operands (.rdata and *ABS* sections) for `&'}}}) {{{ T8947_t1_info_itable: .long (S1i6_srt&-1)-(T8947_t1_info&-1) .long 0 # 0x0 }}} while we want it to be {{{ T8947_t1_info_itable: .long S1i6_srt-T8947_t1_info .long 0 # 0x0 }}} I'm in no way an LLVM expert and know very little about it. Is there a way to make LLVM generate the code we want or are we use the mangler here? Any thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 07:55:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 07:55:24 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.4f731eb905f87fb68d376f2486f371cf@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:"bb857596d1f09260908a0dd4f05cc25c2e822c4c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bb857596d1f09260908a0dd4f05cc25c2e822c4c" Adapt .gitignore (re #8545) This adapts the top-level .gitignore file to match the new situation of base.git, ghc-prim.git, integer-gmp.git, integer-simple.git, and template-haskell.git being folded into ghc.git Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 08:34:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 08:34:32 -0000 Subject: [GHC] #8883: FlexibleContexts checking should happen also on inferred signature In-Reply-To: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> References: <051.4f2c9b2e0f318274939e98656c431beb@haskell.org> Message-ID: <066.69b7a86fa601682380ef97271ce0d05e@haskell.org> #8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------------------+-------------------------- Reporter: Blaisorblade | Owner: Type: bug | jstolarek Priority: normal | Status: closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_fail/T8883 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Lemming): Replying to [comment:17 simonpj]: > I can't get terribly excited about this decision; but I can see the logic, and I'll gladly change the current behaviour if there is support for doing so. (This would affect both inferred and declared types, of course.) As I said, you cannot eliminate all `FlexibleContexts` using an auxiliary variable. You cannot convert {{{class (Functor (PF a)) => C a where}}} to {{{class (Functor b, b ~ PF a) => C a where}}} because you cannot introduce the variable `b` in the superclass constraint. Thus features provided by `FlexibleContexts` cannot always be achieved by `TypeFamilies`, and thus `FlexibleContexts` should not be a "superfeature" of `TypeFamilies`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 10:04:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 10:04:26 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.bcb42a9f2f6f4bb06734a27600b11da3@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"33e585d6eacae19e83862a05b650373b536095fa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="33e585d6eacae19e83862a05b650373b536095fa" Handle base et al. specially in foreachLibrary.mk This adapts the foreachLibrary rule to match the new situation of base.git, ghc-prim.git, integer-gmp.git, integer-simple.git, and template-haskell.git being folded into ghc.git (re #9016), and thus not being mentioned anymore in the `packages` file. One visible effect of this oversight was that the `clean_libraries` make target would fail to clean those packages. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 10:08:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 10:08:00 -0000 Subject: [GHC] #9016: Add System.Exit.die In-Reply-To: <050.e4566798430f089e73482601b9abc89f@haskell.org> References: <050.e4566798430f089e73482601b9abc89f@haskell.org> Message-ID: <065.e8ac73de1fbea6e5225142c1876d4676@haskell.org> #9016: Add System.Exit.die -------------------------------------+------------------------------------ Reporter: SimonHengel | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: This looks like it's done now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 10:31:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 10:31:18 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.e559f26992ab1c0ff9468f7aa9b233e4@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): In [changeset:"33e585d6eacae19e83862a05b650373b536095fa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="33e585d6eacae19e83862a05b650373b536095fa" Handle base et al. specially in foreachLibrary.mk This adapts the foreachLibrary rule to match the new situation of base.git, ghc-prim.git, integer-gmp.git, integer-simple.git, and template-haskell.git being folded into ghc.git (re #9016), and thus not being mentioned anymore in the `packages` file. One visible effect of this oversight was that the `clean_libraries` make target would fail to clean those packages. Signed-off-by: Herbert Valerio Riedel }}} (this was wrongly filed in #9016) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 13:07:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 13:07:13 -0000 Subject: [GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc. In-Reply-To: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> References: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> Message-ID: <069.8f6fe6ef51bdd4cdd2e6b3fd6568bf6f@haskell.org> #9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Moderate (less bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by splinterofchaos): Tentatively, I could, although I wan't sure of the best policy. Perhaps later today, if I have some time but otherwise tomorrow, I might do so. Since GHCi's solution seems to work, I'll just factor it into `InteractiveUI` or a submodule, if more appropriate. Although, on second thought, it would seem more consistent with the current API if instead of predicate functions, I wrote one returning an ADT constructed with something like `AStmt`, `AnImport`, or `ADecl`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 13:19:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 13:19:57 -0000 Subject: [GHC] #9019: Ambiguity checker overeager on "ambiguous" kind variables In-Reply-To: <047.ee327e008dbe14018d786d30dd9de67e@haskell.org> References: <047.ee327e008dbe14018d786d30dd9de67e@haskell.org> Message-ID: <062.2a41c98ec6837449d82ee5c6d4511cfa@haskell.org> #9019: Ambiguity checker overeager on "ambiguous" kind variables -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: I suppose you're right. I was under the assumption that ambiguous types can never be called, in exact contradiction to what is in the user manual. Thanks for taking the time to correct me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 14:43:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 14:43:56 -0000 Subject: [GHC] #5630: External Core needs love In-Reply-To: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> References: <043.b14a974d19f0be56293f1ce6c10b4f25@haskell.org> Message-ID: <058.c6526339f40bb712b62da2a35c409f64@haskell.org> #5630: External Core needs love ---------------------------------------+----------------------------------- Reporter: quux | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 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 kosmikus): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 19:08:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 19:08:14 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.1eec17b23f28a24061bcb97019775be7@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): Ok. I've implemented the mangler based approach. For what I've tested so far it works. It's a bit ugly (UUID magic) and fragile (mangler searches and replaces crlf line ending dependent pattern) because I did not bother to elaborate trivial and boring details. The patch below consists of 2 orthogonal parts: - the first introduces `target datalayout` and `target triple` for 64-bit mingw32 LLVM, it is compatible with LLVM 3.4 and incompatible with current LLVM 3.5svn (`mingw32` was changed to `windows-gnu` in `target triple`). - the second essentially solves the problem, described in this ticket. I've implemented all platform-specific code to be selected in runtime (I believe, LLVM can choose a target dynamically, am I wrong?). And I've tested all on 64-bit GHC 7.9+ and MSYS2 built LLVM 3.4 *only*. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 22:14:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 22:14:45 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.fe1a687f36afe6fd7802926cb66e1281@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * cc: mail@? (added) Comment: Did you also measure -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 22 23:07:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Apr 2014 23:07:02 -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.d89721f94abdf7f3623f2155934392b9@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 Iceland_jack): This would be very nice to have, +1. The possibility of `_` being a shorthand for `undefined` is intriguing. It allows `_` to be a run-of-the-mill pattern exported by `Prelude` that may be redefined by users! The regular wildcard meaning where the expression is `undefined` could be defined as such with the proposed syntax: {{{ pattern _ <- a where _ = undefined failure :: a -> b failure _ = _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 02:25:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 02:25:55 -0000 Subject: [GHC] #9021: rts/linker.c has a memory leak in the dlopen/dlerror code Message-ID: <046.338d06ed46ba2865fda90272f333c349@haskell.org> #9021: rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: hgolden Type: bug | Status: new Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: linker, memory | Operating System: POSIX leak | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Moderate (less | Test Case: than a day) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- The Coverity Scan of ghc highlighted a memory leak (CID 43168) in the internal_dlopen function in rts/linker.c. I wrote this code originally and I recall that there was a memory leak in certain situations, but I didn't fix it at the time because it seemed to be rather minor and only would occur in unusual cases. However, since Coverity identified it, I have thought about it and know how to fix the leak, so I am creating this ticket. The leak occurs because the error message from dlerror must be copied to allocated memory, since the dlerror message is not guaranteed to be stable, and its code is not guaranteed to be reentrant (see POSIX dlopen/dlerror documentation). As I originally coded Trac ticket #2615, I didn't bother to free the allocated memory. The fix is to make sure that the allocated memory is freed once the error message is displayed. Memory is only allocated if there is an error, so it must be freed only when an error has been identified and processed. As far as I know, this bug only exists on a POSIX system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 02:54:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 02:54:22 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.19f08c82fc8415a212e54d2ba99d1f19@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | 7.10.1 Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 7.8.1-rc2 Test Case: | Keywords: simplCore/should_compile/T8848, T8848a | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by carter): @thoughtpolice, if there was a path to getting this into 7.8.3 that I could help with making happen, i'm willing to help do some leg work (though it touches on pieces of GHC i'm not yet familiar with). I believe I can work around this limitation in SPECIALIZE for now, but if there was a way to help get it into 7.8.3, please let me know. (though i'll be excited to revisit my engineering on 7.9 / 7.10 on way or another) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 04:49:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 04:49:43 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch Message-ID: <047.5de523bade6a019122fff089f11b671b@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch ----------------------------+---------------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- In GHC 7.8 TemplateHaskell pretty printer started inserting explicit braces and semicolons. It puts semicolons at the end of the line as opposed to the beginning of the next line. This causes GHC to fail parsing if we try to compile the pretty printed code. {{{ $ cat Foo.hs module Main where import Language.Haskell.TH main = putStrLn $ pprint foo foo :: Dec foo = barD where barD = FunD ( mkName "bar" ) [ Clause manyArgs (NormalB barBody) [] ] barBody = DoE [letxStmt, retxStmt] letxStmt = LetS [ ValD (VarP xName) (NormalB $ LitE $ IntegerL 5) [] ] retxStmt = NoBindS $ AppE returnVarE xVarE xName = mkName "x" returnVarE = VarE $ mkName "return" xVarE = VarE xName manyArgs = map argP [0..9] argP n = VarP $ mkName $ "arg" ++ show n $ ghc-7.8.2 Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo ... $ ./Foo | tee Bar.hs bar arg0 arg1 arg2 arg3 arg4 arg5 arg6 arg7 arg8 arg9 = do {let x = 5; return x} $ ghc Bar.hs [1 of 1] Compiling Main ( Bar.hs, Bar.o ) Bar.hs:2:61: parse error on input `return' }}} I don't know if this is a problem with TH pretty printer or if GHC is supposed to parse semicolons wherever they are.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 06:41:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 06:41:00 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.085d99e14c7f32b39648fe3979520362@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): I've decided to simplify things and returned to [https://ghc.haskell.org/trac/ghc/ticket/8974#comment:12 original design]. No more magics. Just fixing resulting assembler in the mangler. I think the patterns like `..._srt&-1` and `..._info&-1` may not be generated by any *other* code and hence could be rewritten to `..._srt` and `..._info` safely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 06:55:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 06:55:02 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.0cdb9b8d28d0f36a8cc71a8b931a2a3b@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime 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 Wed Apr 23 08:07:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 08:07:50 -0000 Subject: [GHC] #8991: HLint: Illegal instruction (core dumped) In-Reply-To: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> References: <046.b8f1a3100bdf99b93f640175af65e964@haskell.org> Message-ID: <061.6f191f0e6d2b2c7b2c8d4d1afecb2149@haskell.org> #8991: HLint: Illegal instruction (core dumped) -------------------------+------------------------------------------------- Reporter: | Owner: tensor5 | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Keywords: Component: | Architecture: x86_64 (amd64) Compiler | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: https://github.com/haskell- Unknown/Multiple | suite/haskell-src-exts/issues/96 Type of failure: | Runtime crash | Test Case: | Blocking: | -------------------------+------------------------------------------------- Changes (by tensor5): * failure: None/Unknown => Runtime crash Comment: haskell-src-exts-1.15.0.1 crashes again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 08:36:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 08:36:25 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.67940b1f5ae01d191ecc4c61e1f111ea@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:10 td123]: > So I'm not sure if this is an issue anymore. Looks like they were both meant to be added to ghc. Hoopl is mentioned in the release notes. But transformers isn't but it seems like it should be. Thoughts? To be honest, I'm rather confused about your problems with `transformers` and `hoopl`, as those have been in fact become officially GHC-bundled (and registered) core libraries since 7.8.1 and 7.2.1 respectively (see also [wiki:Commentary/Libraries/VersionHistory]) The problems are (afaics) really just only with `haskeline` ,`terminfo`, and `xhtml`, for which only the DSOs get installed but nothing else is done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 17:23:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 17:23:53 -0000 Subject: [GHC] #9023: Error when using empty record update on binary pattern synonym Message-ID: <051.b3d7e289bcacb7e386fa29880cc260de@haskell.org> #9023: Error when using empty record update on binary pattern synonym --------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | --------------------------------+--------------------------------- Using an empty record update with patterns works here {{{ pattern Singleton a = [a] isSingleton :: [a] -> Bool isSingleton Singleton{} = True isSingleton _ = False }}} but fails in the follow example (there may exist a more minimal example) {{{ pattern P a b = Just (a, b) foo P{} = True }}} which outputs (GHC 7.8.2) {{{ $ ghci -ignore-dot-ghci tmp.g2WZtTUkhJ.hs GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( tmp.g2WZtTUkhJ.hs, interpreted ) Var/Type length mismatch: [t{tv aIW} [sk]] [] Ok, modules loaded: Main. *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 17:46:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 17:46:17 -0000 Subject: [GHC] #9024: [CID43166] Memleak in initProfiling2 Message-ID: <047.716b4a0f606a1c37f5f0e638b39f9210@haskell.org> #9024: [CID43166] Memleak in initProfiling2 ------------------------------------+------------------------------------- Reporter: nicolast | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: coverity | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The Coverity scan discovered a (small) memory leak in the error-path of initProfiling2. The attached patch should fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 17:50:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 17:50:45 -0000 Subject: [GHC] #9024: [CID43166] Memleak in initProfiling2 In-Reply-To: <047.716b4a0f606a1c37f5f0e638b39f9210@haskell.org> References: <047.716b4a0f606a1c37f5f0e638b39f9210@haskell.org> Message-ID: <062.2a92986f3fd44ea41abe18432ab2869b@haskell.org> #9024: [CID43166] Memleak in initProfiling2 -------------------------------------+------------------------------------ Reporter: nicolast | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: coverity Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): I already have this on my `wip/coverity` branch (I'm combing through all the errors). Thanks though! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 17:51:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 17:51:11 -0000 Subject: [GHC] #9024: [CID43166] Memleak in initProfiling2 In-Reply-To: <047.716b4a0f606a1c37f5f0e638b39f9210@haskell.org> References: <047.716b4a0f606a1c37f5f0e638b39f9210@haskell.org> Message-ID: <062.bf29f2772b2678b237d32970861f8c56@haskell.org> #9024: [CID43166] Memleak in initProfiling2 -------------------------------------+------------------------------------ Reporter: nicolast | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: coverity Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): BTW, jump on IRC (`#ghc`) and we can coordinate fixes or talk more easily if you'd like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 18:14:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 18:14:01 -0000 Subject: [GHC] #9021: rts/linker.c has a memory leak in the dlopen/dlerror code In-Reply-To: <046.338d06ed46ba2865fda90272f333c349@haskell.org> References: <046.338d06ed46ba2865fda90272f333c349@haskell.org> Message-ID: <061.7e31c01a499b346ccc1c63d4b350cda9@haskell.org> #9021: rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: hgolden Type: bug | Status: new Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: linker, memory Operating System: POSIX | leak, coverity Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by nicolast): * keywords: linker, memory leak => linker, memory leak, coverity -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 18:15:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 18:15:20 -0000 Subject: [GHC] #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code (was: rts/linker.c has a memory leak in the dlopen/dlerror code) In-Reply-To: <046.338d06ed46ba2865fda90272f333c349@haskell.org> References: <046.338d06ed46ba2865fda90272f333c349@haskell.org> Message-ID: <061.6d602da45533b94e86a7c9d61a39a973@haskell.org> #9021: [CID43168] rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: hgolden Type: bug | Status: new Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: linker, memory Operating System: POSIX | leak, coverity Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 18:30:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 18:30:03 -0000 Subject: [GHC] #9025: Core Lint warning with -O (Demand type has 4 arguments ...) Message-ID: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> #9025: Core Lint warning with -O (Demand type has 4 arguments ...) ------------------------------------+------------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The attached small program triggers a Core Lint warning when compiled with `-O`: {{{ bash-3.2$ ghc LintBomb.hs -fforce-recomp -dcore-lint [1 of 1] Compiling LintBomb ( LintBomb.hs, LintBomb.o ) bash-3.2$ ghc LintBomb.hs -fforce-recomp -dcore-lint -O [1 of 1] Compiling LintBomb ( LintBomb.hs, LintBomb.o ) *** Core Lint errors : in result of CorePrep *** {-# LINE 13 "LintBomb.hs #-}: Warning: [RHS of LintBomb.$fEncodable(->)_$cencode :: forall a_arW b_arX. (LintBomb.Encodable a_arW, LintBomb.Encodable b_arX) => (a_arW -> b_arX) -> LintBomb.Enc (a_arW -> b_arX)] Demand type has 4 arguments, rhs has 3 arguments, LintBomb.$fEncodable(->)_$cencode Binder's strictness signature: DmdType *** Offending Program *** LintBomb.encode [InlPrag=[NEVER]] :: forall a_arV. LintBomb.Encodable a_arV => a_arV -> LintBomb.Enc a_arV [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=DmdType , Unf=OtherCon [], RULES: Built in rule for LintBomb.encode: "Class op encode"] LintBomb.encode = \ (@ a_arV) (tpl_sOv [Occ=Once!] :: LintBomb.Encodable a_arV) -> case tpl_sOv of _ [Occ=Dead] { LintBomb.D:Encodable tpl_sOx [Occ=Once] _ [Occ=Dead] -> tpl_sOx } LintBomb.decode [InlPrag=[NEVER]] :: forall a_arV. LintBomb.Encodable a_arV => LintBomb.Enc a_arV -> a_arV [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=DmdType , Unf=OtherCon [], RULES: Built in rule for LintBomb.decode: "Class op decode"] LintBomb.decode = \ (@ a_arV) (tpl_sOz [Occ=Once!] :: LintBomb.Encodable a_arV) -> case tpl_sOz of _ [Occ=Dead] { LintBomb.D:Encodable _ [Occ=Dead] tpl_sOC [Occ=Once] -> tpl_sOC } LintBomb.$fEncodable(->)_$cdecode :: forall a_arW b_arX. (LintBomb.Encodable a_arW, LintBomb.Encodable b_arX) => LintBomb.Enc (a_arW -> b_arX) -> a_arW -> b_arX [GblId, Arity=4, Caf=NoCafRefs, Str=DmdType , Unf=OtherCon []] LintBomb.$fEncodable(->)_$cdecode = \ (@ a_arW) (@ b_arX) ($dEncodable_sOD [Occ=Once] :: LintBomb.Encodable a_arW) ($dEncodable1_sOE [Occ=Once] :: LintBomb.Encodable b_arX) (h_sOF [Occ=Once] :: LintBomb.Enc (a_arW -> b_arX)) (eta_sOG [Occ=Once] :: a_arW) -> let { sat_sOI [Occ=Once] :: LintBomb.Enc b_arX [LclId, Str=DmdType] sat_sOI = let { sat_sOH [Occ=Once] :: LintBomb.Enc a_arW [LclId, Str=DmdType] sat_sOH = LintBomb.encode @ a_arW $dEncodable_sOD eta_sOG } in (h_sOF `cast` (Sub (LintBomb.TFCo:R:Enc(->)[0] _N _N) :: LintBomb.Enc (a_arW -> b_arX) ~# (LintBomb.Enc a_arW -> LintBomb.Enc b_arX))) sat_sOH } in LintBomb.decode @ b_arX $dEncodable1_sOE sat_sOI LintBomb.$fEncodable(->)1 :: forall a_arW b_arX. (LintBomb.Encodable a_arW, LintBomb.Encodable b_arX) => (a_arW -> b_arX) -> LintBomb.Enc a_arW -> LintBomb.Enc b_arX [GblId, Arity=4, Caf=NoCafRefs, Str=DmdType , Unf=OtherCon []] LintBomb.$fEncodable(->)1 = \ (@ a_arW) (@ b_arX) ($dEncodable_sOJ [Occ=Once] :: LintBomb.Encodable a_arW) ($dEncodable1_sOK [Occ=Once] :: LintBomb.Encodable b_arX) (f_sOL [Occ=Once!] :: a_arW -> b_arX) (eta_sOM [Occ=Once] :: LintBomb.Enc a_arW) -> let { sat_sOO [Occ=Once] :: b_arX [LclId, Str=DmdType] sat_sOO = let { sat_sON [Occ=Once] :: a_arW [LclId, Str=DmdType] sat_sON = LintBomb.decode @ a_arW $dEncodable_sOJ eta_sOM } in f_sOL sat_sON } in LintBomb.encode @ b_arX $dEncodable1_sOK sat_sOO LintBomb.$fEncodable(->)_$cencode :: forall a_arW b_arX. (LintBomb.Encodable a_arW, LintBomb.Encodable b_arX) => (a_arW -> b_arX) -> LintBomb.Enc (a_arW -> b_arX) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType , Unf=OtherCon []] LintBomb.$fEncodable(->)_$cencode = (\ (@ a_arW) (@ b_arX) (eta_B3 [Occ=Once] :: LintBomb.Encodable a_arW) (eta_B2 [Occ=Once] :: LintBomb.Encodable b_arX) (eta_B1 [Occ=Once] :: a_arW -> b_arX) -> LintBomb.$fEncodable(->)1 @ a_arW @ b_arX eta_B3 eta_B2 eta_B1) `cast` (forall a_arW b_arX. _R -> _R -> b_arX>_R -> Sub (Sym (LintBomb.TFCo:R:Enc(->)[0] _N _N)) :: (forall a_arW b_arX. (LintBomb.Encodable a_arW, LintBomb.Encodable b_arX) => (a_arW -> b_arX) -> LintBomb.Enc a_arW -> LintBomb.Enc b_arX) ~# (forall a_arW b_arX. (LintBomb.Encodable a_arW, LintBomb.Encodable b_arX) => (a_arW -> b_arX) -> LintBomb.Enc (a_arW -> b_arX))) LintBomb.$fEncodable(->) [InlPrag=[ALWAYS] CONLIKE] :: forall a_arW b_arX. (LintBomb.Encodable a_arW, LintBomb.Encodable b_arX) => LintBomb.Encodable (a_arW -> b_arX) [GblId[DFunId], Arity=2, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []] LintBomb.$fEncodable(->) = \ (@ a_Xs8) (@ b_Xsa) ($dEncodable_sOP :: LintBomb.Encodable a_Xs8) ($dEncodable1_sOQ :: LintBomb.Encodable b_Xsa) -> let { sat_sOS [Occ=Once] :: LintBomb.Enc (a_Xs8 -> b_Xsa) -> a_Xs8 -> b_Xsa [LclId, Str=DmdType] sat_sOS = \ (eta_B2 [Occ=Once] :: LintBomb.Enc (a_Xs8 -> b_Xsa)) (eta_B1 [Occ=Once] :: a_Xs8) -> LintBomb.$fEncodable(->)_$cdecode @ a_Xs8 @ b_Xsa $dEncodable_sOP $dEncodable1_sOQ eta_B2 eta_B1 } in let { sat_sOR [Occ=Once] :: (a_Xs8 -> b_Xsa) -> LintBomb.Enc (a_Xs8 -> b_Xsa) [LclId, Str=DmdType] sat_sOR = (\ (eta_B1 [Occ=Once] :: a_Xs8 -> b_Xsa) -> LintBomb.$fEncodable(->)1 @ a_Xs8 @ b_Xsa $dEncodable_sOP $dEncodable1_sOQ eta_B1) `cast` ( b_Xsa>_R -> Sub (Sym (LintBomb.TFCo:R:Enc(->)[0] _N _N)) :: ((a_Xs8 -> b_Xsa) -> LintBomb.Enc a_Xs8 -> LintBomb.Enc b_Xsa) ~# ((a_Xs8 -> b_Xsa) -> LintBomb.Enc (a_Xs8 -> b_Xsa))) } in LintBomb.D:Encodable @ (a_Xs8 -> b_Xsa) sat_sOR sat_sOS LintBomb.D:Encodable :: forall a_arV. (a_arV -> LintBomb.Enc a_arV) -> (LintBomb.Enc a_arV -> a_arV) -> LintBomb.Encodable a_arV [GblId[DataCon], Arity=2, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []] LintBomb.D:Encodable = \ (@ a_arV) (eta_B2 [Occ=Once] :: a_arV -> LintBomb.Enc a_arV) (eta_B1 [Occ=Once] :: LintBomb.Enc a_arV -> a_arV) -> LintBomb.D:Encodable @ a_arV eta_B2 eta_B1 *** End of Offense *** : Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 18:43:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 18:43:32 -0000 Subject: [GHC] #9026: [CID43163, CID43172] Use correct variable in NULL-check Message-ID: <047.9cd4bd5df68f847024aa2c7225581376@haskell.org> #9026: [CID43163, CID43172] Use correct variable in NULL-check ------------------------------------+------------------------------------- Reporter: nicolast | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: coverity | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I *think* the attached patch fixes the issue reported by Coverity as CID43163, which then fixes CID43172 as a side-effect as well. Please give this a close look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 19:01:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 19:01:41 -0000 Subject: [GHC] #9027: [CID43165] Potential out-of-bounds memory access in hp2ps Message-ID: <047.02e1f2a1e6755794ba47c708d394207d@haskell.org> #9027: [CID43165] Potential out-of-bounds memory access in hp2ps ------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.8.2 Keywords: coverity, hp2ps | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Coverity discovered a potential out-of-bound memory access scenario in hp2ps. I think the attached patch is a possible solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 19:16:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 19:16:23 -0000 Subject: [GHC] #9028: [CID43167] Fix memleak in hp2ps Message-ID: <047.2897bc44eeacf8371c6a38b08e6914cd@haskell.org> #9028: [CID43167] Fix memleak in hp2ps ------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.8.2 Keywords: coverity, hp2ps | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Coverity found a memleak in hp2ps, an allocated buffer not being freed. Attached patch adds the free call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 19:19:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 19:19:00 -0000 Subject: [GHC] #9029: [CID43142] Check return value of sigaction Message-ID: <047.bc149c9b532e70ed1ebc8f70fa97368c@haskell.org> #9029: [CID43142] Check return value of sigaction ------------------------------------+------------------------------------- Reporter: nicolast | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: coverity | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Coverity pointed at a location where the return value of sigaction isn't checked, unlike other occurrences of the function call. This patch adds the call, in line with other code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 23 20:06:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Apr 2014 20:06:25 -0000 Subject: [GHC] #9030: An async exception handler that blocks throwTo until handler finishes running Message-ID: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> #9030: An async exception handler that blocks throwTo until handler finishes running ------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'd like to be able to handle an async exception in thread `A` such that if another thread `B` calls `throwTo`, that call blocks until my handler in `A` has a chance to ''finish''. Currently `throwTo` only blocks until the exception is "received" (which I don't understand precisely). My application is a concurrent FIFO queue library, in which a blocked reader must perform a cleanup action on async exceptions, else the next write will be lost: {{{ testBlockedRecovery = do c <- newChan started <- newEmptyMVar rid <- forkIO (putMVar started () >> readChan c) takeMVar started >> threadDelay 1000 throwTo rid ThreadKilled -- we race the exception-handler in `readChan` here... writeChan c () -- If this write won, then the write was lost and we block indefinitely below: readChan c putStrLn "OK" }}} If in my library I could catch the exception in such a way that `throwTo` blocked until I could handle it, then the test above would pass and the behavior of my Chan would match the standard library. This might seem like a lame example, but I think this functionality would be very generally useful. It would let you recover to a state using an exception handler such that you can reason in terms of linearizability about the pre- and post- exception states; I assume that's sort of the thinking behind making `throwTo` synchronous in the first place. Thanks and please let me know if there's actually a way to do what I'm asking currently, or if any of that wasn't clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 01:15:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 01:15:32 -0000 Subject: [GHC] #9030: An async exception handler that blocks throwTo until handler finishes running In-Reply-To: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> References: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> Message-ID: <063.b0cdeae706a4e5327944a871af1b4f44@haskell.org> #9030: An async exception handler that blocks throwTo until handler finishes running -------------------------------------+------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Why can't you pass an MVar in the thrown exception (which the throwing thread blocks on), which the handler writes to when it is done? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 02:21:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 02:21:09 -0000 Subject: [GHC] #9030: An async exception handler that blocks throwTo until handler finishes running In-Reply-To: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> References: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> Message-ID: <063.e045c2f6247855e6bc2dda37d0f6b9db@haskell.org> #9030: An async exception handler that blocks throwTo until handler finishes running -------------------------------------+------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jberryman): Sure, but the `throwTo` is something the users of my library are doing. Or maybe they're using the `async` lib which is doing the `throwTo ThreadKilled`. In this particular case I think the user will have a mental model of what should happen when a blocked reader thread is killed (which matches the behavior of standard `Chan`), and I'd rather just be able to implement that rather than document weird corner-cases or force users to use a particular function or `Exception` type (although thanks for that idea; I'll probably warm up to that as a workaround). Maybe users never in practice think or care much about what happens when they do a `throwTo` and I just have to worry about not leaving my data structure broken; I'm not really sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 02:44:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 02:44:33 -0000 Subject: [GHC] #9030: An async exception handler that blocks throwTo until handler finishes running In-Reply-To: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> References: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> Message-ID: <063.4dab11f27fd8bd5fb3ba424c079dc0d8@haskell.org> #9030: An async exception handler that blocks throwTo until handler finishes running -------------------------------------+------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): OK, I looked at your example more carefully, I think this alternate design is more appropriate: you should just mask exceptions before reading from the channel. (Now readChan never services an exception once it has successfully read from the MVar, it will finish processing before admitting the exception.) Mask is exactly about setting up the linearizability properly. This won't help if a blocking call inside the mask requires an exception handler to run, but it feels like this should be rare (i.e. you shouldn't hold onto resources if you're going to block). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 03:09:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 03:09:02 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.c14b06c6ba7e1efeec6e2c9bb8680312@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8157, 7883 -------------------------------------+------------------------------------ Comment (by jberryman): FWIW... Replying to [comment:1 tibbe]: > > Atrocious results for the `IORef` solution! It seems like contended `IORef`s don't work well at all. This is my experience. The behavior I've seen is interesting; check out the distribution of samples of a test of 100K concurrent `atomicModifyIORef`s, for 2 cores: [http://htmlpreview.github.io/?https://github.com/jberryman/chan- benchmarks/blob/master/reports/ghc-7.6/bench-multi.vars.html#b2] ...and 8 cores: [http://htmlpreview.github.io/?https://github.com/jberryman/chan- benchmarks/blob/master/reports/ghc-7.6_8-core/bench-multi.vars.html#b2] The `atomicModifyIORefCAS` from atomic-primops doesn't display that nasty spread; with the primitive CAS one thread always wins, but it seems like whatever GHC is doing is causing vicious retry loops, which sometimes stay in phase for awhile. And the fetch-and-add-based counter from `atomic-primops` handles contention far and away better than anything else available. From what I remember I couldn't even measure contention effects going from 2 to 8 contending threads (although I did do both tests on two different machines, so...). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 03:45:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 03:45:55 -0000 Subject: [GHC] #9031: ghc panic: RegAlloc.Liveness.computeLivenss Message-ID: <045.282178438a787f7ffeeca849ab71135d@haskell.org> #9031: ghc panic: RegAlloc.Liveness.computeLivenss -----------------------------------+--------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I have some code where ghc consistently panics with {{{ RegAlloc.Liveness.computeLivenss SCCs aren't in reverse dependent order bad blockId c1kek }}} The only reference I can find to that block in the dumped output is here: {{{ REC c1kej: movq $block{v c1keo}_info,(%rbp) movsd 7(%rbx),%vSSE_s1ivM movsd 15(%rbx),%vSSE_s1ivN movq 96(%rbp),%rbx movsd %vSSE_s1ivN,88(%rbp) movsd %vSSE_s1ivM,96(%rbp) testq $7,%rbx jne _c1keo jmp _c1kep c1kpo: movq $block{v c1kej}_info,(%rbp) movq %vI_s1it5,%rbx movq $0,120(%rbp) testq $7,%rbx jne _c1kej jmp _c1kek, }}} There doesn't appear to be any reference to {{{c1kpo}}} either. Unfortunately I don't yet have a test case I can provide; I'll keep working on that. Building with -dcore-lint and -dcmm-lint don't show any extra errors. This is with ghc-7.8.2 using NCG. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 05:29:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 05:29:58 -0000 Subject: [GHC] #9030: An async exception handler that blocks throwTo until handler finishes running In-Reply-To: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> References: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> Message-ID: <063.82023d9bb740f0d7e7e86132ac89cb07@haskell.org> #9030: An async exception handler that blocks throwTo until handler finishes running -------------------------------------+------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jberryman): I don't really follow you. I'm certainly already masking exceptions in my `readChan` to avoid leaving the structure in a broken state, but an exception can (and must be permitted to) be raised when `readChan` is blocking on an empty queue (blocking on an MVar internally). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 06:47:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 06:47:22 -0000 Subject: [GHC] #9030: An async exception handler that blocks throwTo until handler finishes running In-Reply-To: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> References: <048.f78997c8469988f5f928a5f580d10a47@haskell.org> Message-ID: <063.fce7eeffc269a5727f0b8f28ce948f40@haskell.org> #9030: An async exception handler that blocks throwTo until handler finishes running -------------------------------------+------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Oh sorry, my mistake, readChan is using `modifyMVarMasked`, not `modifyMVar`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 07:09:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 07:09:50 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.33660786dd3b3016a086ea2bd34a1914@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Comment (by simonpj): See [http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2014-04-15 -porting-ghc-a-tale-of-two-architectures.html Colin's excellent blog post] for more details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 07:37:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 07:37:55 -0000 Subject: [GHC] #8965: bootstrapping failure on Linux/ppc64el In-Reply-To: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> References: <047.8a7804e4a781e8a708e338b54d090982@haskell.org> Message-ID: <062.452b6b0078e612215340e4ed8cabd5e1@haskell.org> #8965: bootstrapping failure on Linux/ppc64el --------------------------------------------+----------------------------- Reporter: cjwatson | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------------+----------------------------- Comment (by Simon Peyton Jones ): In [changeset:"31a7bb463b6a3e99ede6de994c1f449c43a9118c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="31a7bb463b6a3e99ede6de994c1f449c43a9118c" Add comments to explain the change to EF_ (Trac #8965) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 07:43:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 07:43:42 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.08c2df2b4ed1f70e47dda28178d7474b@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"79e46aea1643b4dfdc7c846bbefe06b83b535efd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="79e46aea1643b4dfdc7c846bbefe06b83b535efd" Don't eta-expand PAPs (fixes Trac #9020) See Note [Do not eta-expand PAPs] in SimplUtils. This has a tremendously good effect on compile times for some simple benchmarks. The test is now where it belongs, in perf/compiler/T9020 (instead of simpl015). I did a nofib run and got essentially zero change except for cacheprof which gets 4% more allocation. I investigated. Turns out that we have instance PP Reg where pp ppm ST_0 = "%st" pp ppm ST_1 = "%st(1)" pp ppm ST_2 = "%st(2)" pp ppm ST_3 = "%st(3)" pp ppm ST_4 = "%st(4)" pp ppm ST_5 = "%st(5)" pp ppm ST_6 = "%st(6)" pp ppm ST_7 = "%st(7)" pp ppm r = "%" ++ map toLower (show r) That (map toLower (show r) does a lot of map/toLowers. But if we inline show we get something like pp ppm ST_0 = "%st" pp ppm ST_1 = "%st(1)" pp ppm ST_2 = "%st(2)" pp ppm ST_3 = "%st(3)" pp ppm ST_4 = "%st(4)" pp ppm ST_5 = "%st(5)" pp ppm ST_6 = "%st(6)" pp ppm ST_7 = "%st(7)" pp ppm EAX = map toLower (show EAX) pp ppm EBX = map toLower (show EBX) ...etc... and all those map/toLower calls can now be floated to top level. This gives a 4% decrease in allocation. But it depends on inlining a pretty big 'show' function. With this new patch we get slightly better eta-expansion, which makes a function look slightly bigger, which just stops it being inlined. The previous behaviour was luck, so I'm not going to worry about losing it. I've added some notes to nofib/Simon-nofib-notes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 07:46:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 07:46:54 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.ab14980c1a2a83c7c782e44d49b903f4@haskell.org> #9020: Massive blowup of code size on trivial program ----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: perf/compiler/T9020 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by simonpj): * status: new => closed * testcase: => perf/compiler/T9020 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 08:24:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 08:24:16 -0000 Subject: [GHC] #9025: Core Lint warning with -O (Demand type has 4 arguments ...) In-Reply-To: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> References: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> Message-ID: <059.fac67834b3f729fa2f8b962610de33d4@haskell.org> #9025: Core Lint warning with -O (Demand type has 4 arguments ...) -------------------------------------+------------------------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Oddly this works for me. I'm not using precisely 7.8, but close. (In parallel I'm trying to check out a 7.8 branch.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 09:32:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 09:32:03 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.defc0dfd7ab58bf80ce7ad625ef9670c@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by yalas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 11:21:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 11:21:39 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.2b3ab453c464a2db39b27680b5f721b5@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 awson): Also, when on 32-bit the difference between NCG and LLVM is *huge*, the difference on 64-bit (Windows) is also pretty much big - about 55% on Yorkfield, and 40% on Sandy Bridge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 11:54:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 11:54:32 -0000 Subject: [GHC] #9032: Panic with self-import Message-ID: <048.b2b35b617fab282b73adc84f1bdd96f5@haskell.org> #9032: Panic with self-import -----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I've run into GHC panic with this code: {{{ {-# OPTIONS_GHC -fno-warn-unused-imports #-} module Singletons.Star where import Data.Singletons.Prelude import Data.Singletons.Decide import Data.Singletons.CustomStar import Singletons.Nat import Singletons.Star -- <------- HERE data Vec :: * -> Nat -> * where VNil :: Vec a Zero VCons :: a -> Vec a n -> Vec a (Succ n) $(singletonStar [''Nat, ''Int, ''String, ''Maybe, ''Vec]) }}} This is a test in `singletons` package that leads to a panic when run: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: singletons-1.0:Singletons.Star.TFCo:R:DemoteRep*KProxy{tc r0} [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I was unable to minimize the test case. Reproducing requires following steps: 1. Installing latest th-desugar library from github: {{{ git clone https://github.com/goldfirere/th-desugar.git cd th-desugar cabal install }}} 2. Getting latest development version of singletons: {{{ git clone https://github.com/goldfirere/singletons cd singletons git checkout 56734c2bda721cb9a6a3021b901e3b29d6564f0c make tests }}} All should go well. Now you need to edit file `tests/compile-and- dump/Singletons/Star.hs` and uncomment `import Singletons.Star` line. It should be possible to reproduce the bug with: {{{ cd tests/compile-and-dump/ghc -package-name singletons-1.0 Singletons/Star.hs -i../../dist/build -c -XTemplateHaskell }}} It's important to run `make tests` first so that all interface files required by `Star.hs` are in place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 13:11:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 13:11:22 -0000 Subject: [GHC] #9025: Core Lint warning with -O (Demand type has 4 arguments ...) In-Reply-To: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> References: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> Message-ID: <059.ba6a88d3b55acb9f4e4b755af0f11e05@haskell.org> #9025: Core Lint warning with -O (Demand type has 4 arguments ...) -------------------------------------+------------------------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I can reproduce on 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 13:30:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 13:30:22 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.1c983a375abb95b8670da8d91409ad37@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8157, 7883 -------------------------------------+------------------------------------ Comment (by rrnewton): Thanks for these benchmarks! I suspect the problem with atomicModifyIORef's poor behavior may have to do with blackholes? Tracing ghc events will perturb these workloads a bunch I guess, but maybe threadscope could still tell us something wrt blackhole events. By the way, I started peeking at the benchmark code. I don't have a good sense currently of how many cycles each of the following takes in practice: * between a forkIO and the new thread waking up on another CPU. * between two forkIO's from a parent thread waking up (gang synchrony) * delta between two threads blocked on the same MVar waking up I noticed the third method used in MainN.hs and I think this is very standard. However, I wonder if it is worth having all the test threads busy-wait on a memory location to start with a greater degree of synchrony. That way we can have them run for exactly the same time interval and maximize contention over the whole time period ;-). In any case, these benchmarks are great. I'd like to run these on a few different machines with our nightly benchmarking stuff. I read the README but I can't currently build the benchmarks because I don't have chan- split-fast -- where is that? P.S. We currently accumulate benchmark data into Google Fusion Tables (but we'd like to switch to Big Query or Cloud SQL or something). HSBencher does the upload, but it doesn't yet integrate with criterion well. It's more focused on long-running (parallel) benchmarks rather than statistically significant sampling of short runs. Still, adding support for consuming criterion reports would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 14:17:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 14:17:40 -0000 Subject: [GHC] #9033: Type error suppresses defaulting, causes spurious errors Message-ID: <043.e4831100198a7c372c614406acc6de77@haskell.org> #9033: Type error suppresses defaulting, causes spurious errors -----------------------------------------+--------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: defaulting, ambiguous | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- I have a strong feeling this must have been reported already but I can't find a ticket for it, so here goes. If a source file contains a type error, like {{{#!haskell bad :: Bool bad = () }}} then GHC seems to turn off defaulting for ambiguous types in the remainder of the file. So if the same file contains for instance {{{#!haskell square :: Integral i => i -> i square x = x^2 }}} then GHC reports another type error at the ^2: {{{ test.hs:4:7: Couldn't match expected type ?Bool? with actual type ?()? In the expression: () In an equation for ?bad?: bad = () test.hs:7:13: Could not deduce (Integral b0) arising from a use of ?^? from the context (Integral i) bound by the type signature for square :: Integral i => i -> i at test.hs:6:11-30 The type variable ?b0? is ambiguous Note: there are several potential instances: instance Integral Int -- Defined in ?GHC.Real? instance Integral Integer -- Defined in ?GHC.Real? instance Integral GHC.Types.Word -- Defined in ?GHC.Real? In the expression: x ^ 2 In an equation for ?square?: square x = x ^ 2 test.hs:7:14: Could not deduce (Num b0) arising from the literal ?2? from the context (Integral i) bound by the type signature for square :: Integral i => i -> i at test.hs:6:11-30 The type variable ?b0? is ambiguous Note: there are several potential instances: instance Num Double -- Defined in ?GHC.Float? instance Num Float -- Defined in ?GHC.Float? instance Integral a => Num (GHC.Real.Ratio a) -- Defined in ?GHC.Real? ...plus three others In the second argument of ?(^)?, namely ?2? In the expression: x ^ 2 In an equation for ?square?: square x = x ^ 2 }}} The first error is a legitimate type mismatch and it's all fine, but the other two should be resolved with default instance selection -- and it is, once the type error in `bad` is fixed. For example, rewriting `bad` to {{{#!haskell bad :: () bad = () }}} makes *all* errors go away, including the ones on `square`. Default instance selection seems to be turned back on when square is made monomorphic, like {{{#!haskell squareMono :: Int -> Int squareMono x = x^2 }}} Note that the type of x is being fixed, not the 2 that GHC complains about in square. The effect of this is that in a file with a large number of `^2`, `^3`, and such, the error message pointing to the real type error is drowned in all the "could not deduce" messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 14:44:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 14:44:36 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.64d0d5fb6bc7ffedfc8a2424f5a293af@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 awson): The same picture is for 64-bit linux ghc-7.8.1 and LLVM 3.4. NCG loses badly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 16:28:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 16:28:12 -0000 Subject: [GHC] #5578: write access permission of binary result different on OpenBSD In-Reply-To: <048.fdf7529a647d58caef8e610ed8cd679c@haskell.org> References: <048.fdf7529a647d58caef8e610ed8cd679c@haskell.org> Message-ID: <063.c5943989f4d116bca1471f710be7df21@haskell.org> #5578: write access permission of binary result different on OpenBSD --------------------------------------+--------------------------- Reporter: ivdsangen | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Test Suite | Version: 7.2.1 Resolution: duplicate | Keywords: Operating System: OpenBSD | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: getPermissions001 | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------- Changes (by AlainODea): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Duplicate of #8741 which is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 17:58:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 17:58:46 -0000 Subject: [GHC] #9034: GHCi panics when given C++ object file on GNU/Linux Message-ID: <043.041301d73710117066e0bc737fc4c18c@haskell.org> #9034: GHCi panics when given C++ object file on GNU/Linux ------------------------------------------+------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: panic, dynamic linking | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------------+------------------------------- When given a C++ object file, GHCi panics saying that it can't find standard C++ symbols the object file relies on. If foo.cc contains {{{#!C++ #include extern "C" void foo () { std::cout << "bar"; } }}} and is compiled with {{{ g++ -fPIC -c -o foo.o foo.cc }}} then {{{ ghci foo.o -lstdc++ }}} fails with {{{ GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) foo.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14109_0/ghc14109_1.so: undefined symbol: _ZSt4cout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It makes no difference to add -L which was, IIRC, necessary in older versions of GHC. This applies to only GHCi with C++ -- GHC can link C++ object files just fine, while GHCi has no trouble loading C object files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 18:03:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 18:03:33 -0000 Subject: [GHC] #9034: GHCi panics when given C++ object file on GNU/Linux In-Reply-To: <043.041301d73710117066e0bc737fc4c18c@haskell.org> References: <043.041301d73710117066e0bc737fc4c18c@haskell.org> Message-ID: <058.cb6d2e56094395cb47c96bc685d4c5ca@haskell.org> #9034: GHCi panics when given C++ object file on GNU/Linux -------------------------------+------------------------------------------ Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, dynamic linking Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------ Comment (by jun0): Oh, I forgot to mention my environment. I observe this panic on Ubuntu GNU/Linux 13.10 amd64 with g++ (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 18:13:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 18:13:16 -0000 Subject: [GHC] #9035: ghci sometimes displays Word32 as Word64 Message-ID: <050.4f7983c683629a8769fe429d26145378@haskell.org> #9035: ghci sometimes displays Word32 as Word64 --------------------------+------------------------------------------------ Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: GHCi | Operating System: Linux Keywords: | Type of failure: Incorrect result at runtime Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Given this code: {{{ module Main where import Data.Word import Unsafe.Coerce import System.IO nanFloat :: Float nanFloat = unsafeCoerce (maxBound :: Word32) float2word32 :: Float -> Word32 float2word32 = unsafeCoerce nanDouble :: Double nanDouble = unsafeCoerce (maxBound :: Word64) double2word64 :: Double -> Word64 double2word64 = unsafeCoerce main = do putStrLn $ "nanFloat = " ++ show (float2word32 nanFloat) putStrLn $ "nanFloat = " ++ show (float2word32 $ nanFloat + 1) putStrLn $ "nanDouble = " ++ show (double2word64 nanDouble) putStrLn $ "nanDouble = " ++ show (double2word64 $ nanDouble + 1) }}} If we compile with GHC and run, we correctly output: {{{ nanFloat = 4294967295 nanFloat = 4294967295 nanDouble = 18446744073709551615 nanDouble = 18446744073709551615 }}} But if we instead load in ghci, we get the following output: {{{ nanFloat = 4294967295 nanFloat = 140247862083583 nanDouble = 18446744073709551615 nanDouble = 18446744073709551615 }}} For some reason, ghci is displaying (nanFloat+1) as having significantly more digits than can possibly stored in a Word32 value. Test system: Intel Core 2 Duo running Debian with GHC 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 18:25:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 18:25:34 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.6a55a8d6b486f677d66f86781ffafc75@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries/unix | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AlainODea): I have a backport of this fix in the pull request queue for the SmartOS PKGSRC package of GHC 7.6.3. That will resolve it for existing SmartOS users until I get 7.8 working. https://github.com/joyent/pkgsrc-wip/pull/10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 18:35:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 18:35:59 -0000 Subject: [GHC] #9034: GHCi panics when given C++ object file on GNU/Linux In-Reply-To: <043.041301d73710117066e0bc737fc4c18c@haskell.org> References: <043.041301d73710117066e0bc737fc4c18c@haskell.org> Message-ID: <058.5f75ab576c6e317fe08c9f51ffd97558@haskell.org> #9034: GHCi panics when given C++ object file on GNU/Linux -------------------------------+------------------------------------------ Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, dynamic linking Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------ Comment (by carter): could you try using a shared object instead? GHCi 7.8 uses the system dyanmic linker, this problem will likely go away if you use a shared object/dylib -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 18:39:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 18:39:53 -0000 Subject: [GHC] #9034: GHCi panics when given C++ object file on GNU/Linux In-Reply-To: <043.041301d73710117066e0bc737fc4c18c@haskell.org> References: <043.041301d73710117066e0bc737fc4c18c@haskell.org> Message-ID: <058.5921146df7d2d61629855e7095a3ec96@haskell.org> #9034: GHCi panics when given C++ object file on GNU/Linux -------------------------------+------------------------------------------ Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, dynamic linking Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------ Changes (by thoughtpolice): * milestone: => 7.8.3 Comment: That's exactly what he's doing, hence the use of `-fPIC`. Otherwise he'd get an invalid relocation error. I can reproduce this, so it should definitely be marked for 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 19:07:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 19:07:00 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.379249b9f06c5e06d026a13c34a09e2e@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8157, 7883 -------------------------------------+------------------------------------ Comment (by jberryman): Replying to [comment:6 rrnewton]: > By the way, I started peeking at the benchmark code. I don't have a good sense currently of how many cycles each of the following takes in practice: > > * between a forkIO and the new thread waking up on another CPU. ....... > * between two forkIO's from a parent thread waking up (gang synchrony) Good question! Don't have enough cores on my real machine to look at that right now. > * delta between two threads blocked on the same MVar waking up > > I noticed the third method used in MainN.hs and I think this is very standard. However, I wonder if it is worth having all the test threads busy-wait on a memory location to start with a greater degree of synchrony. That way we can have them run for exactly the same time interval and maximize contention over the whole time period ;-). I think that's a good idea. I started doing that in later tests/benchmarks: pass an `IORef Int` to each forked thread, each thread increments the ref and then busy-waits until the counter reaches the target. > > In any case, these benchmarks are great. I'd like to run these on a few different machines with our nightly benchmarking stuff. I read the README but I can't currently build the benchmarks because I don't have chan- split-fast -- where is that? Sorry, this whole project is really just my personal messy scratchwork; even the README is just personal notes that are out of date anyway, and I should probably just remove it. You'll have a hard time building it for a number of reasons, and might have better luck just copy-pasting what looks interesting. I'm happy to help extract and clean up any of them that you're interested in. > > P.S. We currently accumulate benchmark data into Google Fusion Tables (but we'd like to switch to Big Query or Cloud SQL or something). HSBencher does the upload, but it doesn't yet integrate with criterion well. It's more focused on long-running (parallel) benchmarks rather than statistically significant sampling of short runs. Still, adding support for consuming criterion reports would be great. Oh cool, I'd like to look into how you're doing all that. Yeah I was initially nervous about using criterion for these kinds of benchmarks (involving concurrency) but it's actually worked really well, and seeing the distributions has been really enlightening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 19:53:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 19:53:44 -0000 Subject: [GHC] #8972: Investigate adding fast compare-and-swap Int type/primops In-Reply-To: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> References: <044.44e2e6fb7bdb56e73b800f33aea3acf0@haskell.org> Message-ID: <059.f85b9173824bbe6506c39f7d33ba0f53@haskell.org> #8972: Investigate adding fast compare-and-swap Int type/primops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8157, 7883 -------------------------------------+------------------------------------ Comment (by jberryman): Replying to [comment:7 jberryman]: > Replying to [comment:6 rrnewton]: > > > By the way, I started peeking at the benchmark code. I don't have a good sense currently of how many cycles each of the following takes in practice: > > > > * between a forkIO and the new thread waking up on another CPU. > > ....... > Oops sorry! Here I meant to write that I'd sort of benchmarked this, but just added a better test (fork a `putMVar`, then block on `takeMVar` in main thread) which I measure at between 5.4 - 5.8 ?s . So as long as you can get your contention test runs into the milliseconds range those effects should be completely hidden. Feel free to email me if this is distracting from this ticket and you want to chat further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 20:36:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 20:36:09 -0000 Subject: [GHC] #9035: ghci sometimes displays Word32 as Word64 In-Reply-To: <050.4f7983c683629a8769fe429d26145378@haskell.org> References: <050.4f7983c683629a8769fe429d26145378@haskell.org> Message-ID: <065.4cf6bdf01fdf5591b30a9af57c855cd7@haskell.org> #9035: ghci sometimes displays Word32 as Word64 ------------------------------------------------+-------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by hvr): Replying to [ticket:9035 MikeIzbicki]: > For some reason, ghci is displaying (nanFloat+1) as having significantly more digits than can possibly stored in a Word32 value. Part of the reason is, that `Word32` is actually implemented as {{{#!haskell data Word32 = W32# Word# deriving (Eq, Ord) }}} and `Word#` is actually 64bit wide on the `x86_64` platform. So, `Word32` internally //can// actually store more digits than a 32-bit unsigned integer is supposed to hold. What I can't explain, though, is why a single-precision float, which should be 32bit wide, leaks into the hidden unused upper 32bit part of the `Float` (and thus also into the unsafely coerced `Word32`) heap object. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 20:53:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 20:53:27 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.89e7a9ebe21a8afc51404994d19ea7ee@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 GordonBGood): This bug has nothing to do with the difference between the LLVM and the NCG compiler backends; it it well known that NCG isn't that efficient for tight loops. For this bug use case code, NCG has never combined the memory read, the 'and' operation, and the memory write into one read/modify/write instruction whereas LLVM does, which explains the difference between them. This bug has to do with '''why the GHC version 7.8.1 NCG has taken a step backward''' from the previous stable version 7.6.3 in performance due to more register spills and reloads. I only referred to LLVM as proof that the problem seems to be limited to NCG as both NCG and LLVM will share the same C-- output (or at least I think so???) yet NCG shows this step backwards whereas LLVM does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 21:15:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 21:15:42 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.63f27804a825c75b42ddf60b5b48bebc@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 tibbe): Replying to [comment:8 GordonBGood]: > I only referred to LLVM as proof that the problem seems to be limited to NCG as both NCG and LLVM will share the same C-- output (or at least I think so???) yet NCG shows this step backwards whereas LLVM does not. That's a good indication that the NGC is to blame, but it's also possible that the Cmm codegen has regressed but some LLVM optimizations make up for the regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 21:52:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 21:52:38 -0000 Subject: [GHC] #9036: ghc: panic! (the 'impossible' happened) (Binder's type (SingI Symbol ) /= RHS type (String)) Message-ID: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> #9036: ghc: panic! (the 'impossible' happened) (Binder's type (SingI Symbol ) /= RHS type (String)) --------------------------------+--------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: GHC.TypeLits | Operating System: Linux Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | --------------------------------+--------------------------------------- Compilation error message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-linux): cgLookupPanic (probably invalid Core; try -dcore-lint) cobox{v a212} [lid] static binds for: local binds for: main:Debug.Trace.LogTree.Test.$p1AllShow{v r1pg} [gid[ClassOp]] main:Debug.Trace.LogTree.Test.$p2AllShow{v r1ph} [gid[ClassOp]] main:Debug.Trace.LogTree.Test.$p3AllShow{v r1pi} [gid[ClassOp]] main:Debug.Trace.LogTree.Test.$p4AllShow{v r1pj} [gid[ClassOp]] main:Debug.Trace.LogTree.Test.$p5AllShow{v r1pk} [gid[ClassOp]] main:Debug.Trace.LogTree.Test.$p6AllShow{v r1pl} [gid[ClassOp]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Error in -dcore-lint: {{{ [10 of 10] Compiling Debug.Trace.LogTree.Test ( src/Debug/Trace/LogTree/Test.hs, tmp/Debug/Trace/LogTree/Test.o ) *** Core Lint errors : in result of Desugar (after optimization) *** {-# LINE 122 "src/Debug/Trace/LogTree/Test.hs #-}: Warning: [RHS of $dSingI_a20r :: GHC.TypeLits.SingI GHC.TypeLits.Symbol "h"] The type of this binder doesn't match the type of its RHS: $dSingI_a20r Binder's type: GHC.TypeLits.SingI GHC.TypeLits.Symbol "h" Rhs type: [GHC.Types.Char] }}} So, it looks like it's related to !TypeLits. The full -dcore-lint output is attached. To reproduce: 1. git clone https://github.com/ntc2/haskell-call-trace.git 2. cd haskell-call-trace 3. git checkout break-ghc 3. 4. make The dependencies from the .cabal file are: {{{ build-depends: base >=4.6 && <4.7 , template-haskell >=2.8 && <2.9 , ghc-prim >=0.3 && <0.4 , parsec >=3.1 && <3.2 , tagged >=0.7 && <0.8 , transformers >=0.3 && <0.4 , mtl >=2.1 && <2.2 }}} The problematic file is https://github.com/ntc2/haskell-call-trace/blob /break-ghc/src/Debug/Trace/LogTree/Test.hs . I was in the middle of a program-wide change when I ran into this GHC panic; I was using the type errors to guide my fixes. The Test.hs is not type correct, but I don't see how the stuff I changed as anything to do with my use of type-level strings (!TypeLits). The code in the previous commit compiles. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 21:55:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 21:55:17 -0000 Subject: [GHC] #9036: ghc: panic! Binder's type (SingI Symbol ) /= RHS type (String) (was: ghc: panic! (the 'impossible' happened) (Binder's type (SingI Symbol ) /= RHS type (String))) In-Reply-To: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> References: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> Message-ID: <058.bcc2141d92f589ab52c8350f6555ee06@haskell.org> #9036: ghc: panic! Binder's type (SingI Symbol ) /= RHS type (String) ---------------------------------------+-------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: GHC.TypeLits Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+-------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 21:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 21:56:56 -0000 Subject: [GHC] #9036: ghc: panic! Binder's type (SingI Symbol ) /= RHS type (String) In-Reply-To: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> References: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> Message-ID: <058.506a79918af40fc5c3d2672d7daaf8bd@haskell.org> #9036: ghc: panic! Binder's type (SingI Symbol ) /= RHS type (String) ---------------------------------------+-------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: GHC.TypeLits Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+-------------------------------- Comment (by ntc2): The wiki won't let me attach the -dcore-lint output because it's too big (it's about half a MB). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 21:58:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 21:58:53 -0000 Subject: [GHC] #9037: Add option to make selected warnings errors Message-ID: <042.6aee3bd7af8a4db00b8b565ec5ad1d4b@haskell.org> #9037: Add option to make selected warnings errors ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It would be great if GHC offered a `-ferror-*` flag for every `-fwarn-*` flag, that turns the given type of warning into an error. For example, I would like to always error on uninitialized record fields, but don't want to go full `-Werror`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 22:17:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 22:17:18 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict Message-ID: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> #9038: Foreign calls don't make their arguments look strict ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Here's a function that takes a `Double` which is always passed to a `foreign import` expecting a `Double#`. Since the value is always unpacked, I'd expect `add3` to be strict in the `Double` argument and thereby avoid some allocation. {{{ add3 :: Distribution -> Double -> Int64 -> State# RealWorld -> (# State# RealWorld, () #) add3 = \ (distrib_a1uw :: Distribution) (val_a1ux :: Double) (n_a1uy :: Int64) (eta_X22 :: State# RealWorld) -> case myThreadId# eta_X22 of _ { (# ipv_i229, ipv1_i22a #) -> case threadStatus# ipv1_i22a ipv_i229 of _ { (# ipv2_i22e, _, ipv4_i22g, _ #) -> case modInt# ipv4_i22g 8 of ww1_i1NM { __DEFAULT -> case distrib_a1uw `cast` ( :: Distribution ~# Array Stripe) of _ { Array ds2_i22q -> case indexArray# ds2_i22q ww1_i1NM of _ { (# ipv6_i1Nz #) -> case ipv6_i1Nz of _ { Stripe ipv7_s22v ipv8_s22w ipv9_s22x ipv10_s22y -> case {__pkg_ccall main hs_lock Addr# -> State# RealWorld -> (# State# RealWorld #)}_i20J ipv9_s22x ipv2_i22e of _ { (# ds4_i20P #) -> case touch# ipv10_s22y ds4_i20P of s'_i20R { __DEFAULT -> case val_a1ux of _ { D# ds6_d1D8 -> case n_a1uy of _ { I64# ds8_d1Da -> case {__pkg_ccall main hs_distrib_add_n Addr# -> Double# -> Int# -> State# RealWorld -> (# State# RealWorld #)}_d1Dd ipv7_s22v ds6_d1D8 ds8_d1Da s'_i20R of _ { (# ds9_d1Db #) -> case {__pkg_ccall main hs_unlock Addr# -> State# RealWorld -> (# State# RealWorld #)}_i20m ipv9_s22x ds9_d1Db of _ { (# ds10_i20s #) -> case touch# ipv10_s22y ds10_i20s of s'1_i20u { __DEFAULT -> case touch# ipv8_s22w s'1_i20u of s'2_i1YT { __DEFAULT -> (# s'2_i1YT, () #) } } } } } } } } } } } } } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 22:25:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 22:25:40 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.88c4c4d4ad902dac8a8f88b749fc069b@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1592 -------------------------------------+------------------------------------ Changes (by tibbe): * related: => 1592 Comment: #1592 looks related and I think I understanding the reasoning (the earlier `hs_lock` call might exit the program and hence the argument won't be used). I'm fine with this behavior but it'd be nice if I was able to tell the compiler that the function is strict. Adding bang patterns on the arguments has no effect at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 24 22:28:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Apr 2014 22:28:11 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.08e937b9cdeb902034ff3c3bccb0f5c2@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1592 -------------------------------------+------------------------------------ Comment (by tibbe): I tried to add a call to `evaluate val` the very first thing in the function, which resulted in an extra `seq#` call in the function, but it didn't make the function strict. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 04:44:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 04:44:29 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.1285a7396b14bfa235663fa114f51f51@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 GordonBGood): Replying to [comment:9 tibbe]: > Replying to [comment:8 GordonBGood]: > > I only referred to LLVM as proof that the problem seems to be limited to NCG as both NCG and LLVM will share the same C-- output (or at least I think so???) yet NCG shows this step backwards whereas LLVM does not. > > That's a good indication that the NGC is to blame, but it's also possible that the Cmm codegen has regressed but some LLVM optimizations make up for the regression. Alright, as requested by "ezyang" earlier, I added the -ddump-cmm and -ddump-opt-cmm switches to the compilation, with the following results: For version 7.6.3, the CMM code for the loops looks like this: {{{ s1Hq_ret() { label: s1Hq_info rep:StackRep [True, False, True, True, True] } c1XX: _c1Tr::I32 = %MO_S_Gt_W32(R1, I32[Sp + 4]); ; if (_c1Tr::I32 >= 1) goto c1XZ; _s1H9::I32 = %MO_S_Shr_W32(R1, 5); _s1He::I32 = I32[I32[Sp + 8] + 8 + (_s1H9::I32 << 2)]; _s1KJ::I32 = R1; _s1Hh::I32 = _s1KJ::I32 & 31; _s1Hj::I32 = _s1Hh::I32; _s1KI::I32 = 1 << _s1Hj::I32; _s1Hm::I32 = _s1KI::I32 ^ 18446744073709551615; _s1KH::I32 = _s1He::I32 & _s1Hm::I32; I32[I32[Sp + 8] + 8 + (_s1H9::I32 << 2)] = _s1KH::I32; _s1KG::I32 = R1 + 3; R1 = _s1KG::I32; jump s1Hq_info; // [R1] c1XZ: R1 = 1; jump s1HY_info; // [R1] }, }}} and the opt-cmm code for about the same area looks like this: {{{ s1Hq_ret() { Just s1Hq_info: const 933; const 32; } c1XX: ; if (%MO_S_Gt_W32(R1, I32[Sp + 4])) goto c1XZ; _s1H9::I32 = %MO_S_Shr_W32(R1, 5); I32[I32[Sp + 8] + ((_s1H9::I32 << 2) + 8)] = I32[I32[Sp + 8] + ((_s1H9::I32 << 2) + 8)] & (1 << R1 & 31) ^ 18446744073709551615; R1 = R1 + 3; jump s1Hq_info; // [R1] c1XZ: R1 = 1; jump s1HY_info; // [R1] } }}} For version 7.8.1 RC2 the cmm code is about eight times larger with about eight times the number of lines and looks like this {{{ c3jO: _c3jQ::I32 = %MO_S_Gt_W32(_s33c::I32, _s32t::I32); _s33e::I32 = _c3jQ::I32; if (_s33e::I32 >= 1) goto c3jY; else goto c3jZ; c3jY: _s32S::I32 = _s335::I32; goto c3gp; c3jZ: _c3kn::I32 = %MO_S_Shr_W32(_s33c::I32, 5); _s33g::I32 = _c3kn::I32; _s33j::I32 = I32[(_s327::P32 + 8) + (_s33g::I32 << 2)]; _s33j::I32 = _s33j::I32; _c3kq::I32 = _s33c::I32; _s33k::I32 = _c3kq::I32; _c3kt::I32 = _s33k::I32 & 31; _s33l::I32 = _c3kt::I32; _c3kw::I32 = _s33l::I32; _s33m::I32 = _c3kw::I32; _c3kz::I32 = 1 << _s33m::I32; _s33n::I32 = _c3kz::I32; _c3kC::I32 = _s33n::I32 ^ 4294967295; _s33o::I32 = _c3kC::I32; _c3kF::I32 = _s33j::I32 & _s33o::I32; _s33p::I32 = _c3kF::I32; I32[(_s327::P32 + 8) + (_s33g::I32 << 2)] = _s33p::I32; _c3kK::I32 = _s33c::I32 + _s32U::I32; _s33r::I32 = _c3kK::I32; _s33c::I32 = _s33r::I32; goto c3jO; }}} the the optimized opt-cmm code looks like this: {{{ c3jO: if (%MO_S_Gt_W32(_s33c::I32, _s32t::I32)) goto c3jY; else goto c3jZ; c3jY: Sp = Sp + 8; _s32S::I32 = _s335::I32; goto c3gp; c3jZ: _s33g::I32 = %MO_S_Shr_W32(_s33c::I32, 5); I32[(_s327::P32 + 8) + (_s33g::I32 << 2)] = I32[(_s327::P32 + 8) + (_s33g::I32 << 2)] & (1 << _s33c::I32 & 31) ^ 4294967295; _s33c::I32 = _s33c::I32 + _s32U::I32; goto c3jO; }}} It appears to me that the opt-cmm code is about the same but the straight cmm dump has regressed to have lost even the basic optimizations that were there with the older version. It may be that the NCG is using the non-optimized version of CMM as a source where the LLVM generator is using the optimized CMM version, which would explain why LLVM backend generated code is still efficient where NCG generated code is not. Anticipating your next request to look at the STG output, I used the -ddump-stg compiler option to examine that code. The code is too difficult to post here (wordy and lines very long), but a quick examination shows it to be about the same for both versions except that internal constants are recorded as 32-bit numbers in 7.8.1 whereas they were recorded as 64-bit numbers even when referring to 32-bit registers for the older 7.6.3 code; this corresponds to the way they are recorded in both the optimized and non-optimized CMM files by version as listed above. Thus, the bug/regression appears to be go further back than just the new NCG (which is likely using the non-optimized CMM code as input) but also to the CMM code generator in that it is producing much less efficient CMM code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 05:38:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 05:38:43 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.418b6169bfd6c2824481f53144e42ed7@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 jstolarek): I know nothing about 7.6 Cmm generation, but I worked on 7.8 Cmm pipeline this summer so I can offer some guidance. First I'd like to clarify a few things: > both NCG and LLVM will share the same C-- output No, they will not. LLVM backend requires "proc-point splitting". This means we need to turn every Cmm block that is succcesor of more than one block into a separate procedure (at least that is my understanding). See [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/cmm/CmmPipeline.hs#L104 here] and [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/cmm/CmmPipeline.hs#L77 here] to see source of differences between Cmm generated for both backends. [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/cmm/CmmProcPoint.hs#L35 Here] you'll find more on proc-points. > straight cmm dump has regressed to have lost even the basic optimizations that were there with the older version. I'm not sure what was the philosophy behind 7.6 Cmm geneartion but in 7.8 we just generate Cmm from STG in the simplest possible way and then optimize that Cmm. This is similar to generating Core from Haskell and then doing a series of core-to-core transformations. So you need to look at the final Cmm, not the one that comes out from the Cmm->STG pass. > It may be that the NCG is using the non-optimized version of CMM as a source It is using the optimized version. You can see for yourself in the [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/main/HscMain.hs#L1237 tryNewCodeGen function] and its [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/main/HscMain.hs#L1159 call site]. > Anticipating your next request to look at the STG output Bad anticipation :-) Look at generated assembly. Only this can tell you what is the real difference between generated code. I wouldn't be surprised to see something in the lines of #8048. > Thus, the bug/regression appears to be go further back than just the new NCG (which is likely using the non-optimized CMM code as input) but also to the CMM code generator in that it is producing much less efficient CMM code. Let me repeat: a) NCG is using optimized Cmm (look at the code); b) don't look at the un-optimized Cmm - it's irrelevant. Finally, I you want to learn more about Cmm pipeline and Cmm debugging see [wiki:Commentary/Compiler/CodeGen]. Hope that helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 05:40:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 05:40:37 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.3e852354c1675e45e43d7bfdb1148762@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 awson): Replying to [comment:8 GordonBGood]: > This bug has nothing to do with the difference between the LLVM and the NCG compiler backends; it it well known that NCG isn't that efficient for tight loops. For this bug use case code, NCG has never combined the memory read, the 'and' operation, and the memory write into one read/modify/write instruction whereas LLVM does, which explains the difference between them. Oh, I know this. But in the last days I fought with a pile of bugs in 64-bit Windows GHC and I saw a lot of NCG-produced assembly that was bad far beyond what you've described above. Off the top of my head, when I worked with #8974, I saw this: {{{ call suspendThread addq $40,%rsp subq $8,%rsp subq $32,%rsp movq %rax,%rbx movl $0,%eax call performMajorGC addq $40,%rsp movq %rbx,%rcx subq $8,%rsp subq $32,%rsp movl $0,%eax call resumeThread }}} produced by NCG, versus {{{ callq suspendThread movq %rax, %rsi callq performMajorGC movq %rsi, %rcx callq resumeThread }}} produced by LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 06:05:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 06:05:05 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.0dd49600d3ce42e68e46d29493c53945@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 GordonBGood): Replying to [comment:12 awson]: > Replying to [comment:8 GordonBGood]: > > This bug has nothing to do with the difference between the LLVM and the NCG compiler backends; it it well known that NCG isn't that efficient for tight loops. For this bug use case code, NCG has never combined the memory read, the 'and' operation, and the memory write into one read/modify/write instruction whereas LLVM does, which explains the difference between them. > > Oh, I know this. But in the last days I fought with a pile of bugs in 64-bit Windows GHC and I saw a lot of NCG-produced assembly that was bad far beyond what you've described above. > > Off the top of my head, when I worked on #8974, I saw this: > {{{ > call suspendThread > addq $40,%rsp > subq $8,%rsp > subq $32,%rsp > movq %rax,%rbx > movl $0,%eax > call performMajorGC > addq $40,%rsp > movq %rbx,%rcx > subq $8,%rsp > subq $32,%rsp > movl $0,%eax > call resumeThread > }}} > produced by NCG, versus > {{{ > callq suspendThread > movq %rax, %rsi > callq performMajorGC > movq %rsi, %rcx > callq resumeThread > }}} > produced by LLVM. Thanks for your reply and explanation; I've seen the same types of things with 7.6.3 comparing tight loops, but more generally just much less efficient use of registers by NCG as compared to LLVM with many more register spills and reloads; however, the 32-bit version of 7.8.1 RC2's new NCG is even worse as per my bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 06:23:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 06:23:36 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.7b4433d8389c3bfc28d6901d19d37b13@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 GordonBGood): Replying to [comment:11 jstolarek]: > I know nothing about 7.6 Cmm generation, but I worked on 7.8 Cmm pipeline this summer so I can offer some guidance. First I'd like to clarify a few things: Thanks for your explanations and clarifications, some of which I have dug out for myself in the last few minutes - I had already edit added something to the post to which you are replying: > > both NCG and LLVM will share the same C-- output > > No, they will not. LLVM backend requires "proc-point splitting". This means we need to turn every Cmm block that is succcesor of more than one block into a separate procedure (at least that is my understanding). See [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/cmm/CmmPipeline.hs#L104 here] and [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/cmm/CmmPipeline.hs#L77 here] to see source of differences between Cmm generated for both backends. [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/cmm/CmmProcPoint.hs#L35 Here] you'll find more on proc-points. Learned something new here. OK, end result is that using LLVM as a proof that the problem is in NCG because they use the same CMM code is invalid, so it was worth checking the CMM code. > > straight cmm dump has regressed to have lost even the basic optimizations that were there with the older version. > > I'm not sure what was the philosophy behind 7.6 Cmm geneartion but in 7.8 we just generate Cmm from STG in the simplest possible way and then optimize that Cmm. This is similar to generating Core from Haskell and then doing a series of core-to-core transformations. So you need to look at the final Cmm, not the one that comes out from the Cmm->STG pass. OK, I dug that out for myself and now see that in the final pass the CMM code is almost identical for the code that triggers the symptom (other than for the constants recorded as 32-bit depth for 32-bit registers where they used to be recorded as 64-bit even though only 32-bits were used). > > It may be that the NCG is using the non-optimized version of CMM as a source > > It is using the optimized version. You can see for yourself in the [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/main/HscMain.hs#L1237 tryNewCodeGen function] and its [https://github.com/ghc/ghc/blob/f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e/compiler/main/HscMain.hs#L1159 call site]. OK, so given (almost) identical final CMM code, the problem is (likely) not in the CMM code but in the NCG. > > Anticipating your next request to look at the STG output > > Wrong anticipation :-) Look at generated assembly. Only this can tell you what is the real difference between generated code. I wouldn't be surprised to see something in the lines of #8048. > > > Thus, the bug/regression appears to be go further back than just the new NCG (which is likely using the non-optimized CMM code as input) but also to the CMM code generator in that it is producing much less efficient CMM code. I had already posted the inner loop from the assembly as part of the original bug report; someone requested that I post CMM output, which shows it is not (likely) the problem and we are back to NCG as you confirm here. > Let me repeat: a) NCG is using optimized Cmm (look at the code); b) don't look at the un-optimized Cmm - it's irrelevant. Yup, you have made that clear: I never want to look at CMM code ever again. > Finally, I you want to learn more about Cmm pipeline and Cmm debugging see [wiki:Commentary/Compiler/CodeGen]. > > Hope that helps. Yes, I found that link on my own which is how I came to a fuller understanding of the contents of the new CMM file and its relationship to the final opt-cmm file. But you have been most helpful in explaining that LLVM and NCG do not (can not) use the same CMM source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 07:27:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 07:27:21 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.eddc431affb1afb2f851545f78a5e693@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): I have implemented what we discussed ,{{{IfaceTyConParent}}} , the new constructor {{{IfaceDFunTy}}} to {{{IfaceType}}} and printing of extra information when using {{{-dppr-debug}}}. I have submitted a patch for review and also so that we can have something to discuss on. The patch has no tests or new comments yet, it is just work in progress. Every thing works as expected except: 1. I don't really know how to suppress kinds on {{{IfaceTyConApp}}} , when printing {{{TyConApp}}} from {{{TyThing}}} the {{{TyCon}}} is passed along but I don't know what to do in this case. Ex. Something like {{{(~) a a1}}} would actually print {{{(~) * a a1}}} 2. Although I thought I could solve this, strictness annotations are printed as decided not as typed by the user. These are the problems I'm stuck on right now, I just need to clear my head and I'll probably come with solutions, but I can always use some guidance and feedback. Andrei -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 10:07:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 10:07:46 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.bf1fe8a8f159ffdbaa0a6e2f6760230a@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1592 -------------------------------------+------------------------------------ Comment (by simonpj): Can you give the actual example (as simple as possible) so I can reproduce what you are seeing? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 11:15:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 11:15:15 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.af283b8188362f4534e6fb9c5420c701@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): Can you give example tests to demonstrate the issues in (1) and (2)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 11:35:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 11:35:21 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.0b554c4d66a8171a9cb6fa3b6d127451@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): Not sure what you mean. (1) Short example, we just need the types: {{{ context :: a1 ~ a2 => a1 -> a2 context = undefined }}} We should see {{{context :: (~) a1 a2 => a1 -> a2}}} without {{{ -fprint-explicit-kinds }}} but we see {{{context :: (~) * a1 a2 => a1 -> a2}}} as if {{{ -print-explicit-kinds }}} is on. This is because I don't know yet how to suppres kinds from the {{{IfaceTyConApp}}} tys. Same with: {{{ data A x y fun :: A x y -> a fun = undefined }}} where {{{:info}}} shows {{{fun :: A k1 k2 x y -> a}}} (2) {{{ data STest = P !Int | Q {-# UNPACK #-} !Int | R {-# NOUNPACK #-} !Int }}} We see only {{{ IfStrict }}} comming out, so when doing :info we get {{{ data STest = P !Int | Q !Int | R !Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 13:08:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 13:08:55 -0000 Subject: [GHC] #2528: documentation for nub and nubBy should be corrected, extended or removed. In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@haskell.org> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@haskell.org> Message-ID: <062.35da6a49393e13f65daf7011ff9bcdb3@haskell.org> #2528: documentation for nub and nubBy should be corrected, extended or removed. -----------------------------------+------------------------------------ Reporter: jdressel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Changes (by ekmett): * cc: ekmett@?, hvr, ekmett (added) Comment: Jeremy, Reflexivity is violated in base by the instances for `Float`/`Double`, by the behavior around NaN so that law falls apart quickly. `Eq` is also not structural (as demonstrated by `-0` and `0` being `(==)` in `Float`/`Double`), though you didn't offer that one. `Ord` for those is a bit like a funhouse playground. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 13:20:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 13:20:26 -0000 Subject: [GHC] #9029: [CID43142] Check return value of sigaction In-Reply-To: <047.bc149c9b532e70ed1ebc8f70fa97368c@haskell.org> References: <047.bc149c9b532e70ed1ebc8f70fa97368c@haskell.org> Message-ID: <062.54d397cbe935248b36ab0cdba27c397f@haskell.org> #9029: [CID43142] Check return value of sigaction -------------------------------------+------------------------------------ Reporter: nicolast | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: coverity 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 * milestone: => 7.8.3 Comment: Looks good to me. Austin, could you push please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 13:45:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 13:45:00 -0000 Subject: [GHC] #9039: Annotation reification from TH is not looking into HPT Message-ID: <044.cc8f48625f71a576e5f2b834d07d0d9e@haskell.org> #9039: Annotation reification from TH is not looking into HPT -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Moderate (less | at runtime than a day) | Test Case: annth_make Blocked By: | annth_compunits Related Tickets: | Blocking: -------------------------------------+------------------------------------- The annotation reification code only looks into EPS and TCG while trying to find annotations. Unfortunately it forgets HPT, where the annotations for the currently compiling (via --make) package are. The attached patch fixes this issue. Also, I added some test cases that I should have done a long time ago. Sorry for the oversight :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 14:03:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 14:03:28 -0000 Subject: [GHC] #9029: [CID43142] Check return value of sigaction In-Reply-To: <047.bc149c9b532e70ed1ebc8f70fa97368c@haskell.org> References: <047.bc149c9b532e70ed1ebc8f70fa97368c@haskell.org> Message-ID: <062.f709990a5e8045226f43163d9ef6ffb0@haskell.org> #9029: [CID43142] Check return value of sigaction -------------------------------------+------------------------------------ Reporter: nicolast | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: coverity Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nicolast): Austin: in case you find it more convenient to cherry-pick the patch from a git tree instead of applying a Trac attachment, the patches I submitted based on the Coverity results can be found at git://github.com/NicolasT/ghc.git in the 'coverity' branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 14:20:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 14:20:38 -0000 Subject: [GHC] #8488: Annotations should not distinguish type and value In-Reply-To: <046.0175c19cfd098f66da3cc70b6a5deec4@haskell.org> References: <046.0175c19cfd098f66da3cc70b6a5deec4@haskell.org> Message-ID: <061.1afa7ab3fab85af771c70f776a888cb4@haskell.org> #8488: Annotations should not distinguish type and value -------------------------------------+------------------------------------ Reporter: simonpj | Owner: errge 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 errge): I looked into this today, but I got stuck. The issue is two fold. When doing the `HsDecls` change things almost work out, except for prettyprinting, because the current ppr code looks like this: {{{ pprAnnProvenance (ValueAnnProvenance name) = ptext (sLit "ANN") <+> ppr name pprAnnProvenance (TypeAnnProvenance name) = ptext (sLit "ANN type") <+> ppr name }}} So we use `ValueAnnProvenance` vs `TypeAnnProvenance` to decide if we have to print the type keyword after ANN. I tried to add HasOccName constraint at the pretty printer (because for an OccName we know the namespace), but that gets out of hand very quickly, since everywhere we just assume OutputableBndr now. And I was unsure at that point if it's feasible or not to add everywhere (`HsExpr`, `HsDecls`, etc.) HasOccName besides OutputableBndr. The another issue is on the template haskell side. Template Haskell `OccName` is just a `String`, not a `(String, NameSpace)` (maybe I should fix that, btw?). To compensate this mistake we have some heuristics in `TcSplice` to convert TH names to compiler names. Unfortunately this means that after the proposed change if the user has `data X = X`, it would be very hard for the user to put an annotation on the type and on the constructor both. They would have to resort to `NameG`s which are a bit hard to create and not straightforward at all. How should I go forward with this issues? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 14:21:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 14:21:36 -0000 Subject: [GHC] #9039: Annotation reification from TH is not looking into HPT In-Reply-To: <044.cc8f48625f71a576e5f2b834d07d0d9e@haskell.org> References: <044.cc8f48625f71a576e5f2b834d07d0d9e@haskell.org> Message-ID: <059.ec253f433ddf712264aa095f10009b17@haskell.org> #9039: Annotation reification from TH is not looking into HPT -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Moderate (less at runtime | than a day) Test Case: annth_make | Blocked By: annth_compunits | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by errge): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 25 22:21:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Apr 2014 22:21:50 -0000 Subject: [GHC] #9036: ghc: panic! Binder's type (SingI Symbol ) /= RHS type (String) In-Reply-To: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> References: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> Message-ID: <058.717cc64d55dd1a25411efeb2cd3f8662@haskell.org> #9036: ghc: panic! Binder's type (SingI Symbol ) /= RHS type (String) ---------------------------------------+-------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: GHC.TypeLits Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+-------------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: I reduced your program to a single file {{{ {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} module Debug.Trace.LogTree.Test where class UncurryM t where type GetMonad t :: * -> * class Curry a b where type Curried a b :: * gSimple :: String -> String -> [String] gSimple = simpleLogger (return ()) simpleLogger :: Maybe (GetMonad t after) -> t `Curried` [t] simpleLogger _ _ = undefined }}} which compiled with -O gives the same error in 7.6.3 but 7.8.2 gives a typecheck error. I believe this is another instance of bugs #7729, #8142, #8227. So, the issue is fixed in 7.8 and since 7.6 is not actively developed, I'm closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 26 06:47:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Apr 2014 06:47:21 -0000 Subject: [GHC] #9040: HPC doesnt work as expected on mac Message-ID: <045.879578abba86d88f677377cd5560066c@haskell.org> #9040: HPC doesnt work as expected on mac ------------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- on commit 716f3586e23faeb8a4a08e77ebdbfa645c15f9a8 of my in progress project git at github.com:wellposed/numerical-core.git , when i try test library coverage by the following command (asuming dependencies are installed) cabal clean ; cabal configure --enable-tests --enable-library-coverage; cabal build; cabal test i get the following output at the end Writing: numerical-core-0.1.0.0/Numerical.Nat.hs.html hpc: can not find numerical-core-0.1.0.0/Numerical.Array.Shape in ["./.hpc","./dist/hpc/mix/numerical-core-0.1.0.0","./dist/hpc/mix/spec- suite"] this apparently only happens on OS X. here are the build logs from my run https://gist.github.com/cartazio/11312249 (i'll amend that to link to a cleaner output later) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 26 07:13:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Apr 2014 07:13:10 -0000 Subject: [GHC] #9037: Add option to make selected warnings errors In-Reply-To: <042.6aee3bd7af8a4db00b8b565ec5ad1d4b@haskell.org> References: <042.6aee3bd7af8a4db00b8b565ec5ad1d4b@haskell.org> Message-ID: <057.9b3b8f39b2a7135089723d90d7e38e83@haskell.org> #9037: Add option to make selected warnings errors -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by schyler): The rust compiler has a nice system where you don't need tons and tons of flags for warnings/errors/ignores. For example: {{{ Kyles-iMac:~ kvanb$ rustc -W Available lint options: -W Warn about -A Allow -D Deny -F Forbid (deny, and deny all overrides) Available lint checks: name default meaning ---- ------- ------- non-camel-case-types allow types, variants and traits should have camel case names managed-heap-memory allow use of managed (@ type) heap memory owned-heap-memory allow use of owned (~ type) heap memory unstable allow detects use of #[unstable] items (incl. items with no stability attribute) heap-memory allow use of any (~ type or @ type) heap memory unnecessary-qualification allow detects unnecessarily qualified names non-uppercase-statics allow static constants should have uppercase identifiers missing-doc allow detects missing documentation for public members unsafe-block allow usage of an `unsafe` block unreachable-code warn detects unreachable code deprecated warn detects use of #[deprecated] items unused-imports warn imports that are never used warnings warn mass-change the level for lints which produce warnings path-statement warn path statements with no effect ctypes warn proper use of std::libc types in foreign modules dead-assignment warn detect assignments that will never be read unused-unsafe warn unnecessary use of an `unsafe` block unused-mut warn detect mut variables which don't need to be mutable non-uppercase-pattern-statics warn static constants in match patterns should be all caps unrecognized-lint warn unrecognized lint attribute unused-variable warn detect variables which are not used in any way dead-code warn detect piece of code that will never be used unnecessary-allocation warn detects unnecessary allocations that can be eliminated attribute-usage warn detects bad use of attributes type-overflow warn literal out of range for its type type-limits warn comparisons made useless by limits of the types involved while-true warn suggest using loop { } instead of while(true) { } experimental warn detects use of #[experimental] items unknown-features deny unknown features found in create-level #[feature] directives }}} Maybe a long term goal might be to build something similar-ish. Just a thought. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 26 11:29:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Apr 2014 11:29:40 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.ba6e8837f649f291d0b9d8171d1b76a5@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Scott Turner): The patch fails for negative x. {{{ Prelude Data.Complex> (-1)**(0.5) :: Complex Double NaN :+ 0.0 }}} The result needs to be near either 0:+1 or 0:+(-1). The existing exp (log x * y) is basically good as long as x is not 0 or infinity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 26 15:07:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Apr 2014 15:07:55 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.bd00e9c116da770ab94e5f5a5cee9217@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): What about just adding check x>=0? {{{ (x:+0) ** (y:+0) | x >= 0 = (x ** y) :+ 0 x ** y = exp (log x * y) }}} It will be more accurate when raising real numbers to real power: {{{ Prelude Data.Complex> exp (log (2) * 4) :: Complex Double 15.999999999999998 :+ 0.0 Prelude Data.Complex> 2**4 :: Double 16.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 26 15:43:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Apr 2014 15:43:53 -0000 Subject: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# In-Reply-To: <045.5cc829a852152f43b89d9843483d1a41@haskell.org> References: <045.5cc829a852152f43b89d9843483d1a41@haskell.org> Message-ID: <060.afb8fc0cceac9f71c56bd614b07aaf81@haskell.org> #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------ Reporter: malosh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nh2): * cc: mail@? (added) Comment: Would be very useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 26 19:15:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Apr 2014 19:15:15 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.0d24de9847cc642a4067e100afb65591@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+------------------------------------ Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by td123): All I'm saying there is that the release notes do not include transformers as a library that will be included with ghc. If you visit: http://www.haskell.org/ghc/docs/7.8.1/html/users_guide/index.html it doesn't mention any transformers library when it should under section 1.5.3 The rest of the packages I mentioned don't seem to be a problem at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 26 21:35:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Apr 2014 21:35:28 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.61752c1ac64a5bd1af11439dee6c8803@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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): @nomeata Regarding your suspicion that it gets floated out as a constant, I don't see an improvement when getting the upper bound m of `[1..m]` from an IO action. What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 26 22:01:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Apr 2014 22:01:07 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.4c1ffee2db0d6338c78e0c523b221e39@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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 nomeata): It might still get floated out of some local function. Have you tried coming up with a minimal example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 26 23:26:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Apr 2014 23:26:42 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.640f1d40e9955326e1b7f48076cc63d9@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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): @nomeata There is an example I made for this, mentioned in the bug description. The performance I measure for that is: * using `forM_` with `ghc -O`: 2.0 s * using `loop ` with `ghc -O`: 1.6 s * using `forM_` with `ghc -O2`: 0.9 s * using `loop ` with `ghc -O2`: 0.3 s * using `forM_` with `ghc -O2 -fllvm`: 0.75 s * using `loop ` with `ghc -O2 -fllvm`: 0.15 s I tried to make an even smaller benchmark (https://gist.github.com/nh2/11333427) but the performance is identical there although the same thing changes as before. Could you try my two benchmarks and see if you get the same behaviour? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 26 23:53:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Apr 2014 23:53:12 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.bc11f7b5fa0c5cb084e3645c32457565@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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): I have updated the gist at https://gist.github.com/nh2/11333427 to contain both the matmult example (where the difference between `forM_` and `loop` is big) and the simple example (where no difference can be measured). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 01:56:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 01:56:14 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.ecfaffbf766a82ae628da999536ec734@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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 daniel.is.fischer): Replying to [comment:8 nh2]: > I have updated the gist at https://gist.github.com/nh2/11333427 to contain both the matmult example (where the difference between `forM_` and `loop` is big) and the simple example (where no difference can be measured). The simple example doesn't use the same list in different places, so GHC is capable of eliminating it and giving you a loop on unboxed `Int#`s, at least with `-O2`. In the matmult example, you need to conceal the fact that both lists are the same from GHC to get a loop on unboxed `Int#`s. So in principle, GHC can do the desired thing, just the sharing gets in the way. Can somebody think of a situation where sharing is beneficial for `forM_ [a .. b] $ \n -> do ...` code? If not, perhaps special-casing `enumFromTo` arguments for `forM_` etc. is, at least for standard integer types, something to be considered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 02:02:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 02:02:26 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.a11d7ca1d49da56eba46489faedc161a@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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): Preventing it from sharing sounds sensible for me: If the `[a .. b]` was something expensive to compute (a list of primes, say), I suspect any sane person would easily share it manually by declaring it top-level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 02:07:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 02:07:22 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.432866062e3d1e570f2659819a48e817@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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): Replying to [comment:9 daniel.is.fischer]: > The simple example doesn't use the same list in different places Unfortunately, I still get no difference in performance even if I duplicate the loops to forM_ [1.._MAX] $ \i -> do UM.unsafeWrite v 0 i forM_ [1.._MAX] $ \i -> do UM.unsafeWrite v 0 i Any idea? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 15:45:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 15:45:19 -0000 Subject: [GHC] #9041: NCG generates slow loop code Message-ID: <042.98aca4c930785f21daf56def917ee27d@haskell.org> #9041: NCG generates slow loop code -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler (NCG) | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- In http://stackoverflow.com/a/23322255/263061 we compile the code {{{ main :: IO () main = do loop (maxBound :: Word32) $ \i -> do when (i `rem` 100000000 == 0) $ putStrLn "foo" }}} and compare the assembly generated by the NCG and `-fllvm`. The LLVM code is 10 times faster. While the LLVM code looks great, NCG one generated looks quite unfortunate and messy, with a lot of unnecessary `mov`ing around. I am by no means an expert in this, but some of it looks like low hanging potential improvements. This is the '''LLVM code''': {{{ Main_zdwa_info: .LBB1_1: movl $4294967295, %esi /* load the loop bound */ movabsq $-6067343680855748867, %rdi /* load a magic number for the modulus */ jmp .LBB1_2 .LBB1_4: incl %ecx /* loop core start */ .LBB1_2: cmpq %rsi, %rcx je .LBB1_6 /* check loop bound */ /* do the modulus with two multiplications, a shift and a magic number */ /* note : gcc does the same reduction */ movq %rcx, %rax mulq %rdi shrq $26, %rdx imulq $100000000, %rdx, %rax cmpq %rax, %rcx jne .LBB1_4 /* loop core end */ /* Code omitted: print, then return to loop beginning */ .LBB1_6: }}} So the core of the loop is a nice and short: {{{ incl cmpq je movq [division replaced by magic multiplication] mulq shrq imulq cmpq jne }}} Now what '''NCG''' produces: {{{ Main_zdwa_info: /* loop core start */ .Lc3JD: leaq -16(%rbp),%rax /* stack check */ cmpq %r15,%rax jb .Lc3JO /* jump not taken in the normal case */ .Lc3JP: movl $4294967295,%eax /* issue: loading the bound on every iteration */ cmpq %rax,%r14 jne .Lc3JB .Lc3JC: /* Return from main. Code omitted */ .Lc3JB: /* test the index for modulus */ movl $100000000,%eax /* issue: unnecessary moves */ movq %rax,%rbx /* and loading the modulo arg on every iteration */ movq %r14,%rax xorq %rdx,%rdx /* shorter alternative to mov $0,%rdx */ divq %rbx /* issue: doing the division (llvm and gcc avoid this) */ testq %rdx,%rdx jne .Lc3JU /* This jump is usually taken. */ .Lc3JV: /* do the printing. Code omitted. Not relevant */ .Lc3JN: /* increment index and (I guess) restore registers messed up by the printing */ movq 8(%rbp),%rax /* This code is not very relevant because we don't almost never */ incq %rax movl %eax,%r14d addq $16,%rbp jmp Main_zdwa_info .Lc3JU: leaq 1(%r14),%rax /*issue: why not just increment r14? */ movl %eax,%r14d jmp Main_zdwa_info }}} So the core of this loop is {{{ movl [stack check] cmpq jne movl movq movq xorq divq testq jne leaq movl jmp }}} Some issues here: * the stack check is inside the loop * the loop limit is loaded every time inside the loop * the modulo arg is loaded every time inside the loop * we are shuffling around registers * no strength reduction (div is not replaced by cheaper magic number imul) * weird increment using leaq It would be great if somebody with codegen insight could comment on whether these are easy targets for improvement! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 16:05:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 16:05:07 -0000 Subject: [GHC] #9029: [CID43142] Check return value of sigaction In-Reply-To: <047.bc149c9b532e70ed1ebc8f70fa97368c@haskell.org> References: <047.bc149c9b532e70ed1ebc8f70fa97368c@haskell.org> Message-ID: <062.b080b848054cb372959157e73a6d0ba6@haskell.org> #9029: [CID43142] Check return value of sigaction -------------------------------------+------------------------------------ Reporter: nicolast | Owner: thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: coverity 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 HEAD and 7.8 this morning, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 16:05:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 16:05:23 -0000 Subject: [GHC] #9028: [CID43167] Fix memleak in hp2ps In-Reply-To: <047.2897bc44eeacf8371c6a38b08e6914cd@haskell.org> References: <047.2897bc44eeacf8371c6a38b08e6914cd@haskell.org> Message-ID: <062.51cec115b1126cf1eb26ec6dc019ff7e@haskell.org> #9028: [CID43167] Fix memleak in hp2ps -------------------------------------+------------------------------------ Reporter: nicolast | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 7.8.2 Resolution: fixed | Keywords: coverity, hp2ps 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 HEAD and 7.8 this morning, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 16:05:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 16:05:36 -0000 Subject: [GHC] #9027: [CID43165] Potential out-of-bounds memory access in hp2ps In-Reply-To: <047.02e1f2a1e6755794ba47c708d394207d@haskell.org> References: <047.02e1f2a1e6755794ba47c708d394207d@haskell.org> Message-ID: <062.dea99dacdcbfa69fc45b12a4a73c81ef@haskell.org> #9027: [CID43165] Potential out-of-bounds memory access in hp2ps -------------------------------------+------------------------------------ Reporter: nicolast | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 7.8.2 Resolution: fixed | Keywords: coverity, hp2ps 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 HEAD and 7.8 this morning, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 16:06:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 16:06:04 -0000 Subject: [GHC] #9024: [CID43166] Memleak in initProfiling2 In-Reply-To: <047.716b4a0f606a1c37f5f0e638b39f9210@haskell.org> References: <047.716b4a0f606a1c37f5f0e638b39f9210@haskell.org> Message-ID: <062.fcb83787881466f6aa94cb31f07276a4@haskell.org> #9024: [CID43166] Memleak in initProfiling2 -------------------------------------+------------------------------------ Reporter: nicolast | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: coverity 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: Merged in HEAD and 7.8 this morning, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 16:06:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 16:06:47 -0000 Subject: [GHC] #9026: [CID43163, CID43172] Use correct variable in NULL-check In-Reply-To: <047.9cd4bd5df68f847024aa2c7225581376@haskell.org> References: <047.9cd4bd5df68f847024aa2c7225581376@haskell.org> Message-ID: <062.fb999d7b224052279a1b5f195f701936@haskell.org> #9026: [CID43163, CID43172] Use correct variable in NULL-check -------------------------------------+------------------------------------ Reporter: nicolast | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: coverity 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 HEAD and 7.8 this morning, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 16:19:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 16:19:11 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.e91512bedff29b7106924bad81093d75@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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: --------------------------------------------+------------------------------ Changes (by pivo): * cc: pivo@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 16:20:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 16:20:41 -0000 Subject: [GHC] #917: -O introduces space leak In-Reply-To: <062.4116b6ef44458082738cb509a6e4cb7c@haskell.org> References: <062.4116b6ef44458082738cb509a6e4cb7c@haskell.org> Message-ID: <077.bd52987bed744d1a8f8fcd4b8bee22d1@haskell.org> #917: -O introduces space leak -------------------------------------+------------------------------------ Reporter: claus.reinke@? | Owner: Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 6.5 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 pivo): * cc: pivo@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 17:41:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 17:41:04 -0000 Subject: [GHC] #9042: List indenting in case fails Message-ID: <043.cf868ca9b4a544236c1d785c07e59094@haskell.org> #9042: List indenting in case fails ------------------------------------+------------------------------------- Reporter: laar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following code fails to parse {{{ module Temp where t = case [1..2] of [ 1 , 2 ] -> True _ -> False }}} with {{{ Temp.hs:5:9: parse error (possibly incorrect indentation or mismatched brackets) }}} Which relates to the line `, 2`. Indenting both that line and the next one is needed to parse the module. This is contrary to what I suspected. As this vertical layout for lists is allowed as expression, I would also expect it to work for patterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 18:17:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 18:17:29 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.b8487fa52981e82cc1b8389b95a08fcf@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): We could solve (2) by just adding another field to {{{IfaceConDecl}}} in order to also keep the original bang info and not just the representation one. I'm still investigating (1) and trying to find the corect way to distinguish kinds from types using the information we have available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 19:30:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 19:30:19 -0000 Subject: [GHC] #9042: List indenting in case fails In-Reply-To: <043.cf868ca9b4a544236c1d785c07e59094@haskell.org> References: <043.cf868ca9b4a544236c1d785c07e59094@haskell.org> Message-ID: <058.6ac62495bfc65550b60723673e29f3d8@haskell.org> #9042: List indenting in case fails -------------------------------------+------------------------------------ Reporter: laar | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: I would say GHC's behavior in this case is correct. According to (my understanding of) the layout rule, the first character after a layout herald (the `of`, in your case) sets the new indentation level (provided it is not too far left!). So, your open-bracket sets the indentation level. Then, your comma is at the same level of indentation, so GHC inserts a `;` before the comma, causing the parse error. So, that syntax ''is'' available in patterns, as witness by the following (accepted) code: {{{ t = case Just [1..2] of Just [ 1 , 2 ] -> True _ -> False }}} In this example, the `J` of the `Just` in the pattern sets the indentation level, so there's no problem laying out the list vertically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 19:52:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 19:52:35 -0000 Subject: [GHC] #9041: NCG generates slow loop code In-Reply-To: <042.98aca4c930785f21daf56def917ee27d@haskell.org> References: <042.98aca4c930785f21daf56def917ee27d@haskell.org> Message-ID: <057.cf92a6c52c4831fbaebe44bca1a625ab@haskell.org> #9041: NCG generates slow loop code -------------------------------------------------+------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 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 carter): * cc: carter.schonwald@? (added) Comment: Some of these match what are known issues with the ncg. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 21:32:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 21:32:26 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics Message-ID: <047.559a569dcd60e85eae168b55411f2520@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics ------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC.Generics offers a bunch of data types which have valid instances of various type classes in base, such as Functor. There's no good reason not to have these instances, so they should be added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 21:32:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 21:32:40 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.b1948f6d6ace555139f6b82b2265c9d9@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: ocharles Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ocharles): * owner: => ocharles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 22:08:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 22:08:30 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.0c79b6a746c1d4502ca4fa334f1ba5dd@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: ocharles Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ekmett): Makes a lot of sense to me. The missing `Functor`/`Foldable`/`Traversable` instances for these have bitten me before and the instances are entirely determined by their laws / convention. There are a few other instances that make sense uniformly: e.g. `U1`, `Par1`, `Rec1`, and `(:*:)`, and `M1` can also be made instances of `Applicative`, `Monad`, `MonadZip` in a completely unambiguous way determined by the laws just by lifting them from their parts. `(:.:)` admits an unambiguous `Applicative`, but not the others. It might also make sense to look into making the types in there instances of `Generic` / `Generic1` for bootstrapping purposes, and they are currently missing `Typeable` and `Data` instances as well. The instances probably have to live out mostly where the typeclasses come from rather than in the module itself to avoid cycles, but otherwise I don't see any headaches, and they are entirely determined by the definitions of the classes involved, so there is no bikeshedding opportunity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 27 23:22:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Apr 2014 23:22:34 -0000 Subject: [GHC] #9044: createDirectoryIfMissing does not fail on unwritable parent dir Message-ID: <045.f049f1f0d4a8564178ae7c5abb8097be@haskell.org> #9044: createDirectoryIfMissing does not fail on unwritable parent dir -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/directory | Operating System: MacOS X Keywords: | Type of failure: Incorrect result Architecture: Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- On OSX, using `createDirectoryIfMissing` to create a new directory inside a directory for which we do not have write permissions does not throw any exception. Of course it should throw an exception, as it does under Linux. {{{ $ mkdir unwritable $ chmod ugo-w unwritable $ ghci > System.Directory.createDirectoryIfMissing True "unwritable/tst" > }}} On OSX (10.9.2) this does not fail. Under Linux (albeit with 7.6.3) this does throw an exception as expected: {{{ *** Exception: unwritable/tst: createDirectory: permission denied (Permission denied) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 00:18:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 00:18:08 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.147a4cd349628e20d68dfa8fbd1faf40@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 00:30:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 00:30:15 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.fea55256a8481d009264087a5da430bd@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Scott Turner): Adding the x>=0 is an improvement. If it's going to handle one infinity (i.e. +Infinity:+0) it's best to handle them all. There are lots of infinite complex numbers. {{{ (x:+0) ** (y:+0) | x >= 0 = (x ** y) :+ 0 (re:+im) ** 0 | isInfinite re || isInfinite im = 1:+0 x ** y = exp (log x * y) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 05:08:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 05:08:56 -0000 Subject: [GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.3452717f146ba1666d34d6379281798f@haskell.org> #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 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 GordonBGood): The bug is still there with 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 05:11:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 05:11:17 -0000 Subject: [GHC] #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... (was: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3...) In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.8567479a9ab2c2cbcf7ea371ac6b07e6@haskell.org> #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 07:56:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 07:56:38 -0000 Subject: [GHC] #9036: ghc: panic! Binder's type (SingI Symbol ) /= RHS type (String) In-Reply-To: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> References: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> Message-ID: <058.7828a31dfcf298c76ebf27d6f637a258@haskell.org> #9036: ghc: panic! Binder's type (SingI Symbol ) /= RHS type (String) -------------------------------------------------+------------------------- Reporter: ntc2 | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Linux | Keywords: Type of failure: Compile-time crash | GHC.TypeLits Test Case: | Architecture: x86 indexed_types/should_compile/T9036 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * testcase: => indexed_types/should_compile/T9036 Comment: Great. I've added the small example as a regression test, just in case. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 07:56:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 07:56:54 -0000 Subject: [GHC] #9036: ghc: panic! Binder's type (SingI Symbol ) /= RHS type (String) In-Reply-To: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> References: <043.ce4c93e06f09db99cfc87738458b16a5@haskell.org> Message-ID: <058.c261b4af4f4443cab6fce4fe7e31f9b3@haskell.org> #9036: ghc: panic! Binder's type (SingI Symbol ) /= RHS type (String) -------------------------------------------------+------------------------- Reporter: ntc2 | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Linux | Keywords: Type of failure: Compile-time crash | GHC.TypeLits Test Case: | Architecture: x86 indexed_types/should_compile/T9036 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c4e9f243398942499c9f5e21318e6ceb048d5880/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c4e9f243398942499c9f5e21318e6ceb048d5880" Test Trac #9036 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 08:37:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 08:37:22 -0000 Subject: [GHC] #9025: Core Lint warning with -O (Demand type has 4 arguments ...) In-Reply-To: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> References: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> Message-ID: <059.2cb945f695da90056d98f275b2d1c4cc@haskell.org> #9025: Core Lint warning with -O (Demand type has 4 arguments ...) -------------------------------------+------------------------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by darchon): Replying to [comment:1 simonpj]: > Oddly this works for me. I'm not using precisely 7.8, but close. (In parallel I'm trying to check out a 7.8 branch.) > > Simon Perhaps due to 848f595266268f578480ceb4ab1ce4938611c97e ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 08:47:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 08:47:43 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.37092170733fd892956c8f70f60d63dc@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------ Reporter: ocharles | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by dreixel): * owner: ocharles => dreixel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 08:59:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 08:59:33 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.1e5d8c29ac4b3d16902426432cb9f6c6@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I'm fine with this, but I think the error message could be better. "Too many args" is better than "Invalid number of args". It would be easy to generate the same messages as before, by passing `arity` to `classArityErr`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 09:47:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 09:47:01 -0000 Subject: [GHC] #9025: Core Lint warning with -O (Demand type has 4 arguments ...) In-Reply-To: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> References: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> Message-ID: <059.4f178e5b57bb48a5c82b036742f7df88@haskell.org> #9025: Core Lint warning with -O (Demand type has 4 arguments ...) -------------------------------------+------------------------------------ Reporter: conal | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => merge Comment: I think drachon is right. Please merge that commit to 7.8. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 10:00:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 10:00:13 -0000 Subject: [GHC] #9033: Type error suppresses defaulting, causes spurious errors In-Reply-To: <043.e4831100198a7c372c614406acc6de77@haskell.org> References: <043.e4831100198a7c372c614406acc6de77@haskell.org> Message-ID: <058.a0b72a8897edff4ed921e7616c53a60a@haskell.org> #9033: Type error suppresses defaulting, causes spurious errors ---------------------------------+----------------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: defaulting, ambiguous Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | ---------------------------------+----------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ba2e20149e2addaccf5ce3122d3a6e93da696a0a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ba2e20149e2addaccf5ce3122d3a6e93da696a0a" Do type-class defaulting even if there are insoluble constraints The argument in Trac #9033 is very compelling: we should not report 20 errors, fix one, and have the other 19 disappear. They were spurious in the first place. The fix was easy; do type-class defaulting uncondionally, rather than only if there are no insoluble constraints. See Note [When to do type-class defaulting] in TcSimplify. Error messages generally improve, especially tc211 which actually had an example of precisely this phenomenon. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 10:02:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 10:02:54 -0000 Subject: [GHC] #9033: Type error suppresses defaulting, causes spurious errors In-Reply-To: <043.e4831100198a7c372c614406acc6de77@haskell.org> References: <043.e4831100198a7c372c614406acc6de77@haskell.org> Message-ID: <058.a6030d7e4a05e41defeb42f8ef4d4865@haskell.org> #9033: Type error suppresses defaulting, causes spurious errors -------------------------------------+------------------------------------- Reporter: jun0 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: defaulting, Operating System: Unknown/Multiple | ambiguous Type of failure: None/Unknown | Architecture: Unknown/Multiple Test Case: | Difficulty: Unknown typecheck/should_fail/T9033 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T9033 * resolution: => fixed Comment: Good point, thank you! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 10:19:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 10:19:09 -0000 Subject: [GHC] #9017: Confusing error message with PolyKinds In-Reply-To: <044.615421c3033985dd14fef72264fc6cea@haskell.org> References: <044.615421c3033985dd14fef72264fc6cea@haskell.org> Message-ID: <059.19f5ee37590a05a91a683dcfff99bcc7@haskell.org> #9017: Confusing error message with PolyKinds -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I agree that this is bad. We really want more information about what goes wrong with the kind equality. At the moment, when we get a kind-incompatible type equality, such as `a:k ~ b:*`, we generate a "derived" kind equality `k ~ *`. In this case `k` is a skolem constant, so the constraint is insoluble. But derived constraints are discarded before error message generation (for good reason) so we only see the type-equality problem. We could instead generate a "wanted" kind equality; that would not be discarded, and we'd get a better error message: {{{ T9017.hs:8:7: Couldn't match kind `k1' with `*' `k1' is a rigid type variable bound by the type signature for foo :: a b (m b) at T9017.hs:7:8 When matching types a0 :: * -> * -> * a :: k1 -> k -> * Expected type: a b (m b) Actual type: a0 b0 (m0 b0) Relevant bindings include foo :: a b (m b) (bound at T9017.hs:8:1) In the expression: arr return In an equation for `foo': foo = arr return }}} Could still do with improvement (the foralls in the "bound by" message are invisible), but better. Sadly, a new wanted constraint should be used to solve the constraint that gave rise to it, otherwise we generate the same wanted constraint many times. And that is what happens here: we get two copies of the same error messages. With some faff we could elimate the dup, but I think it'd better to wait for Richard's upcoming work in which he gives us full-on kind equalities. Now we can use the kind equality to solve the type equality and all will be well. Meanwhile I attach my diff. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 10:21:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 10:21:44 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.e07dcd52d1b422919fdd68731ee07756@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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): I've got lost in this thread. If someone thinks there is a real bug here, in GHC 7.8, could you re-articulate what you think it is? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 10:32:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 10:32:52 -0000 Subject: [GHC] #9039: Annotation reification from TH is not looking into HPT In-Reply-To: <044.cc8f48625f71a576e5f2b834d07d0d9e@haskell.org> References: <044.cc8f48625f71a576e5f2b834d07d0d9e@haskell.org> Message-ID: <059.ee04ba7176f177adaad85bcc4f326a93@haskell.org> #9039: Annotation reification from TH is not looking into HPT -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Moderate (less at runtime | than a day) Test Case: annth_make | Blocked By: annth_compunits | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by simonpj): Austin could you commit this please? And merge to the 7.8 branch, I guess. Thanks Gergo! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 10:35:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 10:35:41 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.210fd786e4c5aec7aa8a46c024e3cb27@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): I think x raised to 0 must always be equal 1. Even for NaN: {{{ Prelude> (1/0*0) :: Double NaN Prelude> (1/0*0) ** 0 :: Double 1.0 }}} New complex power implementation: {{{ _ ** (0:+0) = 1 :+ 0 x ** (1:+0) = x (x:+0) ** (y:+0) | x >= 0 = (x ** y) :+ 0 x ** y = exp (log x * y) }}} But what about raising zero to complex power? Current implementation gets NaN: {{{ Prelude Data.Complex> exp $ log 0 * (1:+1) :: Complex Double NaN :+ NaN }}} Python throws an exception: {{{ >>> 0**(1+1j) Traceback (most recent call last): File "", line 1, in ZeroDivisionError: 0.0 to a negative or complex power }}} But wolphramalpha gets [https://www.wolframalpha.com/input/?i=0%5E%281%2B1i%29 0], [https://www.wolframalpha.com/input/?i=0%5E%28-1%2B1i%29 infinity] or [https://www.wolframalpha.com/input/?i=0%5E%281i%29 indeterminate]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 10:44:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 10:44:47 -0000 Subject: [GHC] #8488: Annotations should not distinguish type and value In-Reply-To: <046.0175c19cfd098f66da3cc70b6a5deec4@haskell.org> References: <046.0175c19cfd098f66da3cc70b6a5deec4@haskell.org> Message-ID: <061.5059b9e6fef97bc291fb5bfea83af516@haskell.org> #8488: Annotations should not distinguish type and value -------------------------------------+------------------------------------ Reporter: simonpj | Owner: errge 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 simonpj): I'm not sure it's a mistake for TH to just use `String`. TH is meant to be close to Haskell source. And it might impact a lot of people to change this. I'm more open to adding `hasOccName` to `OutputableBndr`. But it seems like a sledgehammer to crack a nut. Unless there are other uses for it, it might be tidier to change `AnndDecl` thus: {{{ data AnnDecl Name = HsAnnotation Name NameSpace (Located (HsExpr name)) }}} with the invariant that the `NameSpace` should match that of the `Name`. That would remove a tiresome additional type, perhaps clarify the intent. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 11:29:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 11:29:32 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.80c13f85b797e72f22321ec15a3238d2@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): We can also add special case for raising to 1 to increase accuracy: {{{ Prelude Data.Complex> exp $ log (1:+2) * (1:+0) :: Complex Double 0.9999999999999998 :+ 2.0000000000000004 }}} By adding this line: {{{ x ** (1:+0) = x }}} But I'm not sure. Is it necessary? This function already has 3 definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 11:30:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 11:30:22 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.59e2f0113ef530919621ef3b0b4100d2@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): By the way, do we need some tests? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:18:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:18:02 -0000 Subject: [GHC] #5019: OS X: ld: warning: could not create compact unwind for _ffi_call_unix64 In-Reply-To: <045.b69a18db2d8262d9c9f3c4458d59e3ad@haskell.org> References: <045.b69a18db2d8262d9c9f3c4458d59e3ad@haskell.org> Message-ID: <060.6d9bf58dc7cfe381e160c0ebe726cdb5@haskell.org> #5019: OS X: ld: warning: could not create compact unwind for _ffi_call_unix64 -------------------------------------------------+------------------------- Reporter: altaic | Owner: Type: bug | Status: Priority: high | closed Component: Compiler | Milestone: 7.8.3 Resolution: fixed | Version: 7.1 Operating System: MacOS X | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: infoneeded => closed * resolution: => fixed Comment: This ticket has actually been fixed for a while now, I think (I remember when it came around, the fix was in `SysTools` somewhere). I'm closing this for now since it seems fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:19:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:19:11 -0000 Subject: [GHC] #7763: Resource limits for Haskell In-Reply-To: <045.162cb8dcc1da76bcf52a024b86650210@haskell.org> References: <045.162cb8dcc1da76bcf52a024b86650210@haskell.org> Message-ID: <060.a8b645c63ef43e327e991508b02a5eec@haskell.org> #7763: Resource limits for Haskell -------------------------------------+------------------------------------ Reporter: ezyang | Owner: simonmar Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Profiling | 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): * milestone: 7.8.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:22:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:22:10 -0000 Subject: [GHC] #8014: Assertion failure when using multithreading in debug mode. In-Reply-To: <047.0dcf2e2192ba50c19f85f9a1379ffc34@haskell.org> References: <047.0dcf2e2192ba50c19f85f9a1379ffc34@haskell.org> Message-ID: <062.ffad669042db6446204c0b04bb2eb253@haskell.org> #8014: Assertion failure when using multithreading in debug mode. -------------------------------------+------------------------------ Reporter: Maxander | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: rts Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8014 -------------------------------------+------------------------------ Changes (by thoughtpolice): * keywords: => rts * difficulty: => Unknown * status: new => infoneeded * related: => #8014 * failure: None/Unknown => Runtime crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:23:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:23:43 -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.afcc5b348d2f2e9a535a58847a201a25@haskell.org> #8475: Library docs: broken links to Foreign.ForeignPtr -------------------------------------+------------------------------------ Reporter: simonmar | Owner: hellertime Type: bug | Status: patch Priority: high | Milestone: 7.8.3 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 thoughtpolice): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:24:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:24:06 -0000 Subject: [GHC] #8014: Assertion failure when using multithreading in debug mode. In-Reply-To: <047.0dcf2e2192ba50c19f85f9a1379ffc34@haskell.org> References: <047.0dcf2e2192ba50c19f85f9a1379ffc34@haskell.org> Message-ID: <062.211be34d4aa94b88c888597f5368cefc@haskell.org> #8014: Assertion failure when using multithreading in debug mode. -------------------------------------+------------------------------ Reporter: Maxander | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: rts Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7189 -------------------------------------+------------------------------ Changes (by thoughtpolice): * related: #8014 => #7189 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:24:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:24:11 -0000 Subject: [GHC] #7189: RTS Assertion Crash In-Reply-To: <049.e87f12b64ebaa9191bcfa3650eeea1a7@haskell.org> References: <049.e87f12b64ebaa9191bcfa3650eeea1a7@haskell.org> Message-ID: <064.e7874209e69beb5bf36db07eb42e39bf@haskell.org> #7189: RTS Assertion Crash -----------------------------------+---------------------------------- Reporter: sseverance | Owner: simonmar Type: bug | Status: infoneeded Priority: normal | Milestone: ? Component: Runtime System | Version: 7.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8014 -----------------------------------+---------------------------------- Changes (by thoughtpolice): * cc: simonmar (added) * related: => #8014 * milestone: 7.8.3 => ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:24:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:24:27 -0000 Subject: [GHC] #7189: RTS Assertion Crash In-Reply-To: <049.e87f12b64ebaa9191bcfa3650eeea1a7@haskell.org> References: <049.e87f12b64ebaa9191bcfa3650eeea1a7@haskell.org> Message-ID: <064.0f7e6543f053e26113550f3445e69faa@haskell.org> #7189: RTS Assertion Crash -----------------------------------+---------------------------------- Reporter: sseverance | Owner: simonmar Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8014 -----------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: ? => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:25:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:25:36 -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.4bac84f357a5c2b38e1ab812f75dd343@haskell.org> #8366: haskeline Posix backend needs #include on Solaris -------------------------------------+------------------------------------- Reporter: oddsignals | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries | Version: 7.7 (other) | Keywords: Resolution: fixed | 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 thoughtpolice): * status: infoneeded => closed * resolution: => fixed * milestone: 7.8.3 => 7.8.1 Comment: This looks fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:25:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:25:52 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.aa82cc0d39b38ff830d537f1d43acced@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): And many other functions can't handle infinity: {{{ Prelude Data.Complex> sqrt (1/0) :: Double Infinity Prelude Data.Complex> sqrt (1/0) :: Complex Double NaN :+ NaN Prelude Data.Complex> log (1/0) :: Double Infinity Prelude Data.Complex> log (1/0) :: Complex Double NaN :+ NaN Prelude Data.Complex> exp (1/0) :: Double Infinity Prelude Data.Complex> exp (1/0) :: Complex Double NaN :+ NaN Prelude Data.Complex> (1/0) * (1/0) :: Double Infinity Prelude Data.Complex> (1/0) * (1/0) :: Complex Double NaN :+ NaN }}} Do we need tickets for them too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:27:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:27:41 -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.5f9a2e67e232458e25ca25af1f7f9787@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: normal | Milestone: 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 thoughtpolice): * priority: high => normal * milestone: 7.8.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:28:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:28:03 -0000 Subject: [GHC] #7028: incorrect link paths for in mac os x after install In-Reply-To: <050.5a49a7d43a2082b8077d439d3e55628b@haskell.org> References: <050.5a49a7d43a2082b8077d439d3e55628b@haskell.org> Message-ID: <065.9dc078921cbe9f9d87e678bb5a07c8c2@haskell.org> #7028: incorrect link paths for in mac os x after install ------------------------------------------+-------------------------------- Reporter: andykitchen | Owner: leroux Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by thoughtpolice): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:28:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:28:48 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.9edffb8816961efaa80363f0e21b3acc@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Changes (by simonpj): * cc: goldfire (added) Comment: Re (2) I'm not too bothered. What you see is what you get. That is, the user wrote `{-# UNPACK #-}` but it didn't happen, so it doesn't show up in the `IfaceSyn`. So I'd just leave it as it is. In your example, I guess you only compiled `STest` without `-O`, else you would see the UNPACK? Re (1) this is actually very much the same kind of issue as with `IfaceFunTy` vs `IfaceDictFunTy`; we don't have quite enough info in the `IfaceType`. I'm adding Richard to the cc list because he is busy unifying types and kinds, and separating the issue of source-code visiblity. To solve (1) we'd need to add a flag saying "I a kind" to each argument of an `IfaceTyConApp`. That's quite painful, `IfaceTyConApp` is very common. It might be better to say: {{{ data IfaceType = .... | IfaceTyConApp IfaceTcArgs | ... data IfaceTcArgs = ITC_Nil | ITC_Type IfaceType IfaceTcArgs | ITC_Kind IfaceKind IfaceTcArgs }}} That would be be simple and would hardly affect in interface files. But I'd like to see what Richard has to say first. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:31:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:31:47 -0000 Subject: [GHC] #7056: Relax static-PE linker object checks (was: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve') In-Reply-To: <045.77f902a9eb98f7595f4855a4413508ee@haskell.org> References: <045.77f902a9eb98f7595f4855a4413508ee@haskell.org> Message-ID: <060.2cef2202602703dfeb4d6476b5423534@haskell.org> #7056: Relax static-PE linker object checks ----------------------------+---------------------------------------------- Reporter: songpp | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown PEi386 Operating System: Windows | Architecture: x86 Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: #2487, #7103, #7889 Blocking: | ----------------------------+---------------------------------------------- Changes (by thoughtpolice): * blockedby: 3658 => * priority: high => normal * failure: GHCi crash => None/Unknown * milestone: 7.8.3 => 7.10.1 * blocking: 8530 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:33:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:33:08 -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.d39a77187e7c601ed3936a5428747e67@haskell.org> #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.7 Resolution: fixed | 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): * status: new => closed * resolution: => fixed Comment: This should now be fixed (the MachO and PE linkers saw some good improvements, and Mach works fine - Windows isn't dynamically linked just yet anyway). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:33:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:33:46 -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.a30e07aa6f7b2c395f8663c6a50b5ba3@haskell.org> #314: #line pragmas not respected inside nested comments --------------------------------------+------------------------------------ Reporter: nobody | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: --------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.3 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:34:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:34:11 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.8b1b41a6aac45520f6920738a3391822@haskell.org> #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs -------------------------------------+------------------------------------ Reporter: clemens | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 6.11 Resolution: | Keywords: codegen Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * keywords: => codegen * priority: high => normal * milestone: 7.8.3 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:35:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:35:45 -0000 Subject: [GHC] #7463: [PATCH] When -keep-hc-files is enabled, foreign stubs *_stub.c should also be kept. In-Reply-To: <042.8dc0ce164f90ead682deaa35f238bd82@haskell.org> References: <042.8dc0ce164f90ead682deaa35f238bd82@haskell.org> Message-ID: <057.49e435f4f9d958795922a53d062025ad@haskell.org> #7463: [PATCH] When -keep-hc-files is enabled, foreign stubs *_stub.c should also be kept. -------------------------------------+------------------------------------ Reporter: PHO | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3472 | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:35:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:35:56 -0000 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@haskell.org> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@haskell.org> Message-ID: <061.ded9ea70e02be107852c925162246d16@haskell.org> #3472: Porting through .hc files broken -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7463 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * priority: high => low * milestone: 7.8.3 => ? Comment: Cross compilation is far more capable now, so I'm lowering the priority of this ticket and punting the milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:36:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:36:05 -0000 Subject: [GHC] #7463: [PATCH] When -keep-hc-files is enabled, foreign stubs *_stub.c should also be kept. In-Reply-To: <042.8dc0ce164f90ead682deaa35f238bd82@haskell.org> References: <042.8dc0ce164f90ead682deaa35f238bd82@haskell.org> Message-ID: <057.4a89c99adacba828fac1abe41e583976@haskell.org> #7463: [PATCH] When -keep-hc-files is enabled, foreign stubs *_stub.c should also be kept. -------------------------------------+------------------------------------ Reporter: PHO | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3472 | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:41:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:41:32 -0000 Subject: [GHC] Batch modify: #2528, #4259, #4900, #5941, #5945, #5972, #6004, #6018, #6024, #6037, #6040, #6056, #6070, #6089, #6092, #6101, #6107, #6124, #6132, #6149, #7015, #7033, #7044, #7048, #7057, #7063, #7066, #7072, #7078, #7081, #7098, #7104, #7109, #7114, #7133, #7141 Message-ID: <20140428124132.BA28524069@ghc.haskell.org> Batch modification to #2528, #4259, #4900, #5941, #5945, #5972, #6004, #6018, #6024, #6037, #6040, #6056, #6070, #6089, #6092, #6101, #6107, #6124, #6132, #6149, #7015, #7033, #7044, #7048, #7057, #7063, #7066, #7072, #7078, #7081, #7098, #7104, #7109, #7114, #7133, #7141 by thoughtpolice: milestone to 7.10.1 Comment: Moving to 7.10.1. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:48:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:48:05 -0000 Subject: [GHC] #9039: Annotation reification from TH is not looking into HPT In-Reply-To: <044.cc8f48625f71a576e5f2b834d07d0d9e@haskell.org> References: <044.cc8f48625f71a576e5f2b834d07d0d9e@haskell.org> Message-ID: <059.afcd7f42480a4cd2a4dca03e3e1eb5fe@haskell.org> #9039: Annotation reification from TH is not looking into HPT -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Moderate (less at runtime | than a day) Test Case: annth_make | Blocked By: annth_compunits | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:50:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:50:30 -0000 Subject: [GHC] #7097: linker fails to load package with binding to foreign library In-Reply-To: <042.8652c19ed572825fd749b02b3e025d62@haskell.org> References: <042.8652c19ed572825fd749b02b3e025d62@haskell.org> Message-ID: <057.09b6fc9dc0247d920b42e058d7451fa7@haskell.org> #7097: linker fails to load package with binding to foreign library -----------------------------------+------------------------------------- Reporter: nus | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2283 #3242 #1883 -----------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * blockedby: 3658 => Comment: Yes, it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:51:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:51:11 -0000 Subject: [GHC] Batch modify: #7181, #7204, #7240, #7380, #7389, #7443, #7460, #7625, #7672, #7687, #7779, #7789, #3977, #8258 Message-ID: <20140428125111.AB79924069@ghc.haskell.org> Batch modification to #7181, #7204, #7240, #7380, #7389, #7443, #7460, #7625, #7672, #7687, #7779, #7789, #3977, #8258 by thoughtpolice: milestone to 7.10.1 Comment: Moving to 7.10.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:57:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:57:35 -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.ff3f1c2a47bc0c765e5343712f4155d8@haskell.org> #781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 6.5 Resolution: fixed | Keywords: getEnvironment Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: getEnvironment01 | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * blockedby: 3658 => * milestone: 7.8.3 => 7.8.1 Comment: This is now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 12:58:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 12:58:35 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.31444f4f7e879525aebe17184f6167a6@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by owst): I've uploaded a new patch, which preserves the original messages, as per Simon's suggestion. Owen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:00:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:00:16 -0000 Subject: [GHC] Batch modify: #3831, #3927, #4243, #4374, #4879, #5218, #5442, #5780, #5902, #5910, #6017, #6022, #7068, #7152, #7198, #7200, #7289, #7300, #7428 Message-ID: <20140428130017.01CF424069@ghc.haskell.org> Batch modification to #3831, #3927, #4243, #4374, #4879, #5218, #5442, #5780, #5902, #5910, #6017, #6022, #7068, #7152, #7198, #7200, #7289, #7300, #7428 by thoughtpolice: milestone to 7.10.1 Comment: Bumping priority down (these tickets haven't been closely followed or fixed in 7.4), and moving out to 7.10 and out of 7.8.3. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:01:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:01:23 -0000 Subject: [GHC] Batch modify: #3658, #3831, #3927, #4243, #4374, #4879, #5218, #5442, #5780, #5902, #6017, #6022, #7068, #7152, #7198, #7200, #7289, #7300, #7428 Message-ID: <20140428130123.4406B24069@ghc.haskell.org> Batch modification to #3658, #3831, #3927, #4243, #4374, #4879, #5218, #5442, #5780, #5902, #6017, #6022, #7068, #7152, #7198, #7200, #7289, #7300, #7428 by thoughtpolice: priority to normal Comment: Actually dropping priority. :) -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:02:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:02:17 -0000 Subject: [GHC] #8993: Fold NullaryTypeClasses into MPTC In-Reply-To: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> References: <043.65ed25b8b715c45bb39df76dc411a5dc@haskell.org> Message-ID: <058.67b081ae7772f3756048fa55dfa5e6fe@haskell.org> #8993: Fold NullaryTypeClasses into MPTC -------------------------------------+------------------------------------ Reporter: owst | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.10.1 Comment: Awesome, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:04:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:04:54 -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.a518057251111cb6fcc1ab1ce7984b17@haskell.org> #8676: RTS headers don't compile as C++ ----------------------------------------+---------------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | 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 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:06:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:06:00 -0000 Subject: [GHC] #8176: Language extensions not registered In-Reply-To: <045.79de2871493b7288b102990a0c57a18c@haskell.org> References: <045.79de2871493b7288b102990a0c57a18c@haskell.org> Message-ID: <060.444ba605b53ab7038973bd035a629023@haskell.org> #8176: Language extensions not registered ------------------------------------------+-------------------------------- Reporter: duncan | Owner: Type: bug | thoughtpolice Priority: normal | Status: closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: tests/driver/T4437.hs | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: 7.8.3 => 7.8.1 Comment: This is now all cleaned up and fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:06:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:06:12 -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.aca74564b0f54175d85af3ddb35052f1@haskell.org> #8676: RTS headers don't compile as C++ ----------------------------------------+---------------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: 7.8.3 => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:06:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:06:35 -0000 Subject: [GHC] #8121: Gitolite Migration In-Reply-To: <042.663c31b719b049f2ee4d2dc9fcb02490@haskell.org> References: <042.663c31b719b049f2ee4d2dc9fcb02490@haskell.org> Message-ID: <057.7ae411e331b6c38021fba721040254fe@haskell.org> #8121: Gitolite Migration -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.8.3 Component: Trac & Git | Version: Resolution: fixed | Keywords: admin git 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: Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:07:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:07:10 -0000 Subject: [GHC] #7810: make show VALUE=VAR depends on ghc-stage1 In-Reply-To: <046.882d6e4c467938612df87a18a7ab7d09@haskell.org> References: <046.882d6e4c467938612df87a18a7ab7d09@haskell.org> Message-ID: <061.7e68ba12a24f91ecf883daa5131eb370@haskell.org> #7810: make show VALUE=VAR depends on ghc-stage1 -------------------------------------+------------------------------------ Reporter: kgardas | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.8.3 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): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:08:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:08:41 -0000 Subject: [GHC] #7723: iOS patch no 12: Itimer.c doesn't work on iOS In-Reply-To: <056.9767e70565312fbbb95062bfdcdf193a@haskell.org> References: <056.9767e70565312fbbb95062bfdcdf193a@haskell.org> Message-ID: <071.4b58c620cf84c5e0a2cc09ea12358586@haskell.org> #7723: iOS patch no 12: Itimer.c doesn't work on iOS --------------------------------------+------------------------------ Reporter: StephenBlackheath | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Other | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------ Changes (by thoughtpolice): * cc: simonmar (added) * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:09:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:09:06 -0000 Subject: [GHC] #7694: LLVM: bootstrapping with LLVM 3.2 does not work In-Reply-To: <048.505a8ac79c35dd5a21a9810c5c3fde72@haskell.org> References: <048.505a8ac79c35dd5a21a9810c5c3fde72@haskell.org> Message-ID: <063.20d2d6b717bc0cdcf99b5ab7176c553c@haskell.org> #7694: LLVM: bootstrapping with LLVM 3.2 does not work ----------------------------------------+---------------------------------- Reporter: gmainland | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.7 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => wontfix Comment: I think this is pretty much a WONTFIX. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:09:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:09:16 -0000 Subject: [GHC] #7694: LLVM: bootstrapping with LLVM 3.2 does not work In-Reply-To: <048.505a8ac79c35dd5a21a9810c5c3fde72@haskell.org> References: <048.505a8ac79c35dd5a21a9810c5c3fde72@haskell.org> Message-ID: <063.3d988006a4ba20f945850e08c6ab5777@haskell.org> #7694: LLVM: bootstrapping with LLVM 3.2 does not work ----------------------------------------+---------------------------------- Reporter: gmainland | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: 7.8.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:11:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:11:16 -0000 Subject: [GHC] #7621: Cross-build for QNX ARM smashes stack when using FunPtr wrappers In-Reply-To: <049.3ecf497466e0b6871bd293a116f06c8c@haskell.org> References: <049.3ecf497466e0b6871bd293a116f06c8c@haskell.org> Message-ID: <064.3f5a29b98427c3135e748f4779af3c0c@haskell.org> #7621: Cross-build for QNX ARM smashes stack when using FunPtr wrappers -------------------------+------------------------------------------------- Reporter: | Owner: singpolyma | Status: infoneeded Type: bug | Milestone: 7.8.3 Priority: | Version: 7.7 normal | Keywords: qnx unregisterised cross- Component: | compile Compiler (FFI) | Architecture: arm Resolution: | Difficulty: Unknown Operating System: QNX | Blocked By: Type of failure: | Related Tickets: Runtime crash | Test Case: | Blocking: 7610 | -------------------------+------------------------------------------------- Changes (by thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:13:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:13:20 -0000 Subject: [GHC] #7329: ghc-7.6.1 win64: internal error: R_X86_6 4_PC32: High bits are set in WSAGetLastError In-Reply-To: <044.bbe36d2399d5cf2eb745edefeb232913@haskell.org> References: <044.bbe36d2399d5cf2eb745edefeb232913@haskell.org> Message-ID: <059.bfc2ab2c113a02f9c4d4c33c688c1799@haskell.org> #7329: ghc-7.6.1 win64: internal error: R_X86_6 4_PC32: High bits are set in WSAGetLastError ---------------------------------+------------------------------------ Reporter: dagit | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: GHCi | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: hvr (added) * status: new => closed * resolution: => fixed * blockedby: 3658 => Comment: This should now be fixed I believe with all of Kyril's work. Do reopen if it still happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:15:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:15:04 -0000 Subject: [GHC] Batch modify: #7140, #7158, #7161, #7169, #7190, #7245, #7246, #7253, #7258, #7259, #7269, #7275, #7283, #7285, #7296, #7297, #7307, #7330, #7331, #7335, #7337, #7353, #7367, #7371, #7373, #7374, #7378, #7379, #7395, #7398, #7401, #7413, #7414, #7430, #7437, #7450, #7459, #7461, #7473, #7484, #7492, #7494, #7495, #7503, #7505, #7511, #7535, #7539, #7542, #7543, #7544, #7593, #7596, #7604, #7606, #7608, #7610, #7611, #7621, #7623, #7624, #7634, #7635, #7637, #7643, #7644, #7650, #7660, #7666, #7668, #7669, #7670, #7723, #7727, #7730, #7735, #7736, #7741, #7746, #7765, #7788, #7790, #7803, #7808, #7810, #7828, #7829, #7831, #7936, #8034, #8036, #8174, #8198, #8226, #8229, #8285, #8620, #8623, #8647, #8761 Message-ID: <20140428131504.AB63E24069@ghc.haskell.org> Batch modification to #7140, #7158, #7161, #7169, #7190, #7245, #7246, #7253, #7258, #7259, #7269, #7275, #7283, #7285, #7296, #7297, #7307, #7330, #7331, #7335, #7337, #7353, #7367, #7371, #7373, #7374, #7378, #7379, #7395, #7398, #7401, #7413, #7414, #7430, #7437, #7450, #7459, #7461, #7473, #7484, #7492, #7494, #7495, #7503, #7505, #7511, #7535, #7539, #7542, #7543, #7544, #7593, #7596, #7604, #7606, #7608, #7610, #7611, #7621, #7623, #7624, #7634, #7635, #7637, #7643, #7644, #7650, #7660, #7666, #7668, #7669, #7670, #7723, #7727, #7730, #7735, #7736, #7741, #7746, #7765, #7788, #7790, #7803, #7808, #7810, #7828, #7829, #7831, #7936, #8034, #8036, #8174, #8198, #8226, #8229, #8285, #8620, #8623, #8647, #8761 by thoughtpolice: milestone to 7.10.1 Comment: Moving to 7.10.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:15:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:15:50 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.08c8e5e7c20ee46cd371e3d8cab1575d@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): Re (2) I'm not too bothered either but maybe we should ask around on the mailing lists ? Regarding compiling without {{{-O}}} I just work with one big file that has all the things that interest this bug in ghci. Re (1) I was wondering when the unification of types and kinds might happen, it's good to hear it is happening. And also , not enough information is the problem I feard but as I'm only starting to get the hang of things I hoped there was something I overlooked. I will wait then and see what can be done. Andrei -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:17:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:17:44 -0000 Subject: [GHC] #6098: debugger does not know the correct type for a newtype field In-Reply-To: <046.a6a3ed9e9606c79c8b19751897c4a128@haskell.org> References: <046.a6a3ed9e9606c79c8b19751897c4a128@haskell.org> Message-ID: <061.e74b6069117fef23df79df185b077496@haskell.org> #6098: debugger does not know the correct type for a newtype field ------------------------------------------------+-------------------------- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.5 Resolution: | Keywords: Operating System: Linux | debugger bindings Type of failure: Incorrect result at runtime | Architecture: x86_64 Test Case: | (amd64) Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * cc: hvr (added) * owner: ptc => * priority: high => normal * milestone: 7.8.3 => 7.10.1 Comment: Moving out to 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:18:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:18:29 -0000 Subject: [GHC] #8728: Segmentation fault in Cabal In-Reply-To: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> References: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> Message-ID: <062.f51f2c2d55beb68a224bd7c19519df25@haskell.org> #8728: Segmentation fault in Cabal --------------------------------------+----------------------------- Reporter: heatsink | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Cabal Operating System: MacOS X | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+----------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: 7.8.3 => 7.8.1 Comment: This one was fixed with one of Simon's code generator changes for 7.8.1, actually. Yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:18:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:18:54 -0000 Subject: [GHC] #8070: Use a captcha for trac registrations In-Reply-To: <044.f2a36852e2772074b1987ebd0c5e0ae0@haskell.org> References: <044.f2a36852e2772074b1987ebd0c5e0ae0@haskell.org> Message-ID: <059.128d085035c85eb6deffeaae7d67f2e3@haskell.org> #8070: Use a captcha for trac registrations -------------------------------------+------------------------------------ Reporter: igloo | Owner: hvr Type: task | Status: new Priority: high | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: trac admin Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * version: 7.6.3 => * milestone: 7.8.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:20:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:20:09 -0000 Subject: [GHC] #8933: process007: internal error: checkStackFrame: weird activation record found on stack In-Reply-To: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> References: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> Message-ID: <062.ce3452bfbd0fac0633e3bd8b7ce2616e@haskell.org> #8933: process007: internal error: checkStackFrame: weird activation record found on stack ----------------------------------+------------------------------------ Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: ppc Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: process007 | Blocked By: Blocking: 8819 | Related Tickets: #8819 ----------------------------------+------------------------------------ Changes (by thoughtpolice): * keywords: => ppc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:20:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:20:52 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.4d7fbc97ec45aa9f7802f8b28152ddbd@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | 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 thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:21:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:21:06 -0000 Subject: [GHC] #8731: long compilation time for module with large data type and partial record selectors In-Reply-To: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> References: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> Message-ID: <060.767d298445b3beb37efa7c3849236e48@haskell.org> #8731: long compilation time for module with large data type and partial record selectors -------------------------------------------------+------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 7.10.1 Resolution: | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: Compile-time performance bug | Keywords: Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * milestone: 7.8.3 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:22:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:22:24 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.f5801e15378822864b627c3d770e0822@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:22:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:22:25 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.1222c47c729d9cd4ae34b8915e80e9b5@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): Also if Richard needs any help moving this along I will be glad to lend a hand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:22:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:22:37 -0000 Subject: [GHC] #7475: Mysterious Data.Word Segmentation Fault in GHCi In-Reply-To: <042.0d1079999ffac31cce4c009249dd86e7@haskell.org> References: <042.0d1079999ffac31cce4c009249dd86e7@haskell.org> Message-ID: <057.5edbc238b8ec30ac0ce459a4ba1bd1bb@haskell.org> #7475: Mysterious Data.Word Segmentation Fault in GHCi -----------------------------+--------------------------------------------- Reporter: VKS | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: ghci, data.word, segfault Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: 3658 Test Case: | Related Tickets: Blocking: | -----------------------------+--------------------------------------------- Changes (by thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:25:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:25:57 -0000 Subject: [GHC] #7241: GHC-7.6.1 panics on template haskell code In-Reply-To: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> References: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> Message-ID: <061.5a41454a3c217b822e37603015cb0b74@haskell.org> #7241: GHC-7.6.1 panics on template haskell code ---------------------------------------+----------------------------------- Reporter: akamaus | Owner: simonpj Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.6.1 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 thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:26:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:26:29 -0000 Subject: [GHC] #7767: "internal error: evacuate: strange closure type 154886248" crash In-Reply-To: <047.0b39935f5cb7eca0e8f06868adf551de@haskell.org> References: <047.0b39935f5cb7eca0e8f06868adf551de@haskell.org> Message-ID: <062.90827cf7d2aecf232091b107b804ff14@haskell.org> #7767: "internal error: evacuate: strange closure type 154886248" crash ------------------------------------+---------------------------------- Reporter: rodlogic | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.2 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): * status: new => infoneeded * milestone: 7.8.3 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:26:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:26:34 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" In-Reply-To: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> References: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> Message-ID: <063.d90482699655fda47991950bad27033d@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.1-rc2 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): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:27:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:27:42 -0000 Subject: [GHC] #7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range) In-Reply-To: <046.db8982aae960140182b517f2adaa75d5@haskell.org> References: <046.db8982aae960140182b517f2adaa75d5@haskell.org> Message-ID: <061.c2c29fc89ad856c55087dba0fa864f4c@haskell.org> #7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range) ----------------------------------------+------------------------------ Reporter: kgardas | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+------------------------------ Changes (by thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:28:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:28:01 -0000 Subject: [GHC] #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) In-Reply-To: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> References: <052.b5316a423cedc87fa6cecb2672f617b3@haskell.org> Message-ID: <067.b1b92d257c554bf72ef99d7d4eb202d3@haskell.org> #7651: Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) ----------------------------------------+---------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:28:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:28:26 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.f513f7896f4e1eb38c7ad74c0f595f05@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, Operating System: Linux | System Time Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.3 => 7.10.1 Comment: Whatever happens, I doubt this will be fixed in time for 7.8.3, but someone can bump it back if so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:29:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:29:12 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.103e206ec92fa256b62d3ad9aa1aad94@haskell.org> #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: thoughtpolice Type: bug | Status: new Priority: low | Milestone: 7.8.3 Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * priority: high => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:29:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:29:21 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.aed4407be48484ce892f6d0b01f6fad9@haskell.org> #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * priority: low => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:30:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:30:40 -0000 Subject: [GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked In-Reply-To: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> References: <047.f5c1e98e88fb0e535a65a8bb76dcd836@haskell.org> Message-ID: <062.2c6390634f1dbbc93deaedcaff64d2cc@haskell.org> #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked -------------------------------+------------------------------------------- Reporter: rwbarton | Owner: thoughtpolice Type: bug | Status: new Priority: low | Milestone: 7.8.3 Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * priority: high => low Comment: This is merged, the testsuite needs investigation, but I believe this should be fine with MSYS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:32:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:32:48 -0000 Subject: [GHC] #8362: Filesystem related tests failed on solaris (SmartOS) In-Reply-To: <045.1583030feb3ddc515a1e21f0a79caa57@haskell.org> References: <045.1583030feb3ddc515a1e21f0a79caa57@haskell.org> Message-ID: <060.2504636222af7a8846ddc57954be7006@haskell.org> #8362: Filesystem related tests failed on solaris (SmartOS) ------------------------------------------------+-------------------------- Reporter: leroux | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: libraries (other) | Version: 7.6.3 Resolution: | Keywords: Operating System: Solaris | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * priority: high => normal Comment: I'm bumping this to normal priority. I believe Alain is testing on SmartOS, perhaps he has an idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:33:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:33:31 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.31605b60bc750b8c2e83a2df0b95ef96@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------ Reporter: thoughtpolice | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.3 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:34:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:34:27 -0000 Subject: [GHC] Batch modify: #7490, #8746 Message-ID: <20140428133427.B409824069@ghc.haskell.org> Batch modification to #7490, #8746 by thoughtpolice: priority to normal milestone to 7.10.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:35:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:35:44 -0000 Subject: [GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) In-Reply-To: <045.6e47836af0f0e307f79949999a773a19@haskell.org> References: <045.6e47836af0f0e307f79949999a773a19@haskell.org> Message-ID: <060.f26cebc9bf766540887b459d4cde5e55@haskell.org> #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ---------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:37:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:37:16 -0000 Subject: [GHC] #8933: process007: internal error: checkStackFrame: weird activation record found on stack In-Reply-To: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> References: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> Message-ID: <062.09ed8a46c79f54cd2296fc79998b22c4@haskell.org> #8933: process007: internal error: checkStackFrame: weird activation record found on stack ----------------------------------+------------------------------------ Reporter: trommler | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: ppc Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: process007 | Blocked By: Blocking: 8819 | Related Tickets: #8819 ----------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:37:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:37:55 -0000 Subject: [GHC] #8975: Troubling build warning with GHC 7.8.1 on Mavericks In-Reply-To: <050.6c30c380c8c9fe6f1e3c389f821c0db6@haskell.org> References: <050.6c30c380c8c9fe6f1e3c389f821c0db6@haskell.org> Message-ID: <065.7438ed20da80479e68f644d9f6aba372@haskell.org> #8975: Troubling build warning with GHC 7.8.1 on Mavericks --------------------------------+---------------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:38:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:38:55 -0000 Subject: [GHC] #5019: OS X: ld: warning: could not create compact unwind for _ffi_call_unix64 In-Reply-To: <045.b69a18db2d8262d9c9f3c4458d59e3ad@haskell.org> References: <045.b69a18db2d8262d9c9f3c4458d59e3ad@haskell.org> Message-ID: <060.df3b087b4d4a7665b8b23999060a8074@haskell.org> #5019: OS X: ld: warning: could not create compact unwind for _ffi_call_unix64 -------------------------------------------------+------------------------- Reporter: altaic | Owner: Type: bug | Status: Priority: high | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.1 Operating System: MacOS X | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | x86_64 (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * milestone: 7.8.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:39:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:39:02 -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.a039311be32fcdbe38a0004b6f45c799@haskell.org> #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | 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.3 => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:39:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:39:51 -0000 Subject: [GHC] #7679: Regression in -fregs-graph performance In-Reply-To: <047.9e26897513125de7441d596a4b30ee54@haskell.org> References: <047.9e26897513125de7441d596a4b30ee54@haskell.org> Message-ID: <062.05d31c8caab51f0ee0dbf564150d59a0@haskell.org> #7679: Regression in -fregs-graph performance --------------------------------------------+------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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 thoughtpolice): * milestone: 7.8.3 => 7.10.1 Comment: Let's move this to 7.10 and decide what to do then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:40:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:40:43 -0000 Subject: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o In-Reply-To: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> References: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> Message-ID: <060.bd66349d0327c00349e45bcb42a01721@haskell.org> #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o ----------------------------------------+---------------------------------- Reporter: mrothe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * priority: high => normal * status: new => infoneeded * milestone: 7.8.3 => 7.10.1 Comment: Since this looks like a binutils bug, I'm lowering priority and moving out of 7.8.3 - can we do anything to help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:41:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:41:14 -0000 Subject: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version In-Reply-To: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> References: <048.2fa9f9bf55f3bc1ae7013e61d58e551e@haskell.org> Message-ID: <063.e6f713a10b06fa13f36392fbcf9c5664@haskell.org> #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------------------+------------------------- Reporter: cetinsert | Owner: Type: bug | dterei Priority: normal | Status: new Component: Compiler (LLVM) | Milestone: 7.8.3 Resolution: | Version: Operating System: Windows | 7.6.1-rc1 Type of failure: Incorrect warning at | Keywords: llvm compile-time | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:41:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:41:39 -0000 Subject: [GHC] #7273: Binary size increase in nofib/grep between 7.6.1 and HEAD In-Reply-To: <047.56a3d4f639e4f19c232c77ec82adbeca@haskell.org> References: <047.56a3d4f639e4f19c232c77ec82adbeca@haskell.org> Message-ID: <062.db54b7e3ed8b319e774927267d723c96@haskell.org> #7273: Binary size increase in nofib/grep between 7.6.1 and HEAD -------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.3 => 7.10.1 Comment: Not happening in the 7.8 window, most likely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:42:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:42:54 -0000 Subject: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o In-Reply-To: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> References: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> Message-ID: <060.81919b541d427203416da0baa48201dd@haskell.org> #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o ----------------------------------------+---------------------------------- Reporter: mrothe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by octoploid): Replying to [comment:6 thoughtpolice]: > Since this looks like a binutils bug, I'm lowering priority and moving out of 7.8.3 - can we do anything to help? Sure. Just don't use relative paths in linker scripts. Use full paths instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:49:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:49:51 -0000 Subject: [GHC] #9018: GHC suppresses too much kind information In-Reply-To: <046.c3a6990365759bc20aaf2b78e8937436@haskell.org> References: <046.c3a6990365759bc20aaf2b78e8937436@haskell.org> Message-ID: <061.b2b27d32102e6f25827da54c5a6dfac2@haskell.org> #9018: GHC suppresses too much kind information -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"2f3ea95285d0cccc2a999e7572d8fb78dc2ea441/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2f3ea95285d0cccc2a999e7572d8fb78dc2ea441" Print for-alls more often (Trac #9018) We now display the foralls of a type if any of the type variables is polykinded. This put kind polymorphism "in your face" a bit more often, but eliminates a lot of head scratching. The user manual reflects the new behaviour. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 13:54:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 13:54:17 -0000 Subject: [GHC] #9018: GHC suppresses too much kind information In-Reply-To: <046.c3a6990365759bc20aaf2b78e8937436@haskell.org> References: <046.c3a6990365759bc20aaf2b78e8937436@haskell.org> Message-ID: <061.43ad18236766ce25c7de330282c4a6ac@haskell.org> #9018: GHC suppresses too much kind information -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 14:04:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 14:04:35 -0000 Subject: [GHC] #9025: Core Lint warning with -O (Demand type has 4 arguments ...) In-Reply-To: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> References: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> Message-ID: <059.171f41e5b4b612fee5eb2f2e20337d15@haskell.org> #9025: Core Lint warning with -O (Demand type has 4 arguments ...) -------------------------------------+------------------------------------ Reporter: conal | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 14:05:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 14:05:53 -0000 Subject: [GHC] #8121: Gitolite Migration In-Reply-To: <042.663c31b719b049f2ee4d2dc9fcb02490@haskell.org> References: <042.663c31b719b049f2ee4d2dc9fcb02490@haskell.org> Message-ID: <057.404811d3df465835ff066b06e6f58dd9@haskell.org> #8121: Gitolite Migration -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: admin git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 14:06:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 14:06:32 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.c076bf447f2ac7bc5480f876a0e54709@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by simonmar): * status: new => infoneeded Comment: Marking infoneeded as I'm not sure how to repro this. Ideally I need to see the exact command line that GHC was invoked with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 14:15:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 14:15:09 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.87d8020f94e7a99cd8317b06f4150f70@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by nomeata): * owner: simonmar => Comment: I?ll work on it when I find the time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 14:15:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 14:15:34 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.9e2c6335cc2c518e6169da8c78507b6e@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by nomeata): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 14:16:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 14:16:04 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.3873727a06f09e34437e38918dbcf337@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by nomeata): * owner: => nomeata Comment: (Sorry for the multiple changes, but I don?t the the permissions to assign the ticket to me otherwise.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 14:16:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 14:16:17 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.e5d5d2a9e9975142197bcf67943d06d7@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by nomeata): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 15:17:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 15:17:08 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.7d17f57e25e17404d2b8b89eb02bb459@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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): @simonpj: Summary: 1) I reported that my manually written loop is much faster than `forM_ [1..n]` in some cases, suggesting that in some cases optimizing the list away doesn't work well. 2) nomeata said some technical things that are a bit beyond me. 3) I submit two benchmarks in the gist at ?https://gist.github.com/nh2/11333427, a "matmult" benchmark where there is a big difference between `forM_` and the hand-written `loop`, and a "simple" benchmark where they are equally fast. 4) Daniel suspects the slow case comes from using the same syntactical list twice, and that in this case GHC floats it out to share it, which breaks eliminating it. He suggests we might special-case `enumFromTo` when used with `forM_` to prevent it. 5) I give a counter example for his suspicion, by changing my "simple" benchmark, where using the same list twice gives the same good performance as using it once. I get the same behaviour for 7.6 and 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 15:21:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 15:21:51 -0000 Subject: [GHC] #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 Message-ID: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8866 | ------------------------------------+------------------------------------- Found this while working on something else. This is a real bug that can cause random `scavenge_stack` failures at runtime, and could be the cause of #8866. I have a fix on the way... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 15:26:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 15:26:10 -0000 Subject: [GHC] #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 In-Reply-To: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> References: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> Message-ID: <062.475fb7d0f5ec4c69d644f2b23bfdf7ee@haskell.org> #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8866 -------------------------------------+------------------------------------ Comment (by thoughtpolice): Excellent! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 15:30:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 15:30:52 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.19266296d0fb74a0daa926d9d65afaf6@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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 daniel.is.fischer): Slight correction, @Niklas, it's not a suspicion that it's the floating out of the list to the top-level and consequently the use of the list for looping instead of unboxed `Int#`s, that is direct from the core (`-ddump- simpl` is your friend in all matters related to performance). The question is under which exact circumstances GHC floats the list out. To answer that, you need somebody knowing how GHC works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 15:51:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 15:51:25 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print Message-ID: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> #9046: Panic in GHCi when using :print ------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When using names generated by :print, GHCi panics sometimes. According to #ghc, this is reproducible on ''x86_64-apple-darwin'' as well, but is not an issue in ''7.6.3 x86_64 linux''. {{{ > let a = [1] > :print a a = (_t1::Num t => [t]) > :t _t1 ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcTyVarDetails t{tv avD} [tv] > _t1 }}} From playing around with it a bit, this seems to have something to do with polymorphic values. {{{ -- No panic > let a = [1 :: Int] > let a = 1 :: Int > let a = "hello" -- Panic > let a = [1] > let a = 1 > let a = "hello" -- With -XOverloadedStrings }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 17:17:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 17:17:14 -0000 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@haskell.org> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@haskell.org> Message-ID: <061.4c353286707799b2e3899733cfa5e099@haskell.org> #3472: Porting through .hc files broken -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: closed Priority: low | Milestone: ? Component: Build System | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7463 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I think we can just close this. If there are remaining issues with cross- compilation then open separate tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 17:37:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 17:37:01 -0000 Subject: [GHC] #7241: GHC-7.6.1 panics on template haskell code In-Reply-To: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> References: <046.90fb67f2e6cf54f5d0d42d95e66dba19@haskell.org> Message-ID: <061.9fff7caadb4c46332334c6c40cde72b6@haskell.org> #7241: GHC-7.6.1 panics on template haskell code ---------------------------------------+----------------------------------- Reporter: akamaus | Owner: simonpj Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.6.1 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 Yuras): It seems to be a duplicate of or similar to #8932 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 17:39:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 17:39:00 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.d538a5e5262a08f2a52b7e38ffe05889@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): Testing [https://ghc.haskell.org/trac/ghc/attachment/ticket/8539/complex_functions.patch complex_functions.patch]: ||= =||= Double =||= Complex Double (patched) =||= Complex Double (current) =|| || 1/0 || Infinity || Infinity :+ 0.0 || Infinity || || 1/0*0 || Nan || NaN :+ 0.0 || NaN :+ NaN || || 1/0/0 || Infinity || Infinity :+ 0.0 || NaN :+ NaN || || 1/0/2 || Infinity || Infinity :+ 0.0 || NaN :+ NaN || || (1/0)*(1/0) || Infinity || Infinity :+ 0.0 || NaN :+ NaN || || sqrt (1/0) || Infinity || Infinity :+ 0.0 || NaN :+ NaN || || exp (1/0) || Infinity || Infinity :+ 0.0 || NaN :+ NaN || || exp (-1/0) || 0.0 || 0.0 :+ 0.0 || NaN :+ NaN || || log (1/0) || Infinity || Infinity :+ 0.0 || NaN :+ NaN || || log (-1/0) || NaN || Infinity :+ 3.141592653589793 || NaN :+ NaN || || 0!**0 || 1.0 || 1.0 :+ 0.0 || NaN :+ NaN || || 0!**2 || 0.0 || 0.0 :+ 0.0 || NaN :+ NaN || || 0!**(-2) || Infinity || Infinity :+ 0.0 || NaN :+ NaN || || 2!**4 || 16.0 || 16.0 :+ 0.0 || 15.999999999999998 :+ 0.0 || || 3!**1 || 3.0 || 3.0 :+ 0 || 3.0000000000000004 :+ 0.0 || || sqrt (-4) || NaN || 0.0 :+ 2.0 || (-0.0) :+ 2.0 || This even partially fixes old raise to power implementation: ||= =||= Double =||= Complex Double (patched) =||= Complex Double (current) =|| || exp (log 0 * 2) || 0.0 || 0.0 :+ 0.0 || NaN :+ NaN || || exp (log 0 * 0) || 1.0 || NaN :+ 0.0 || NaN :+ NaN || || exp (log 0 * (-2)) || Infinity || Infinity :+ 0.0 || NaN :+ NaN || What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 18:39:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 18:39:13 -0000 Subject: [GHC] #9047: Testsuite fails on OS X Mavericks Message-ID: <047.0afe1c31b6584b760336c379b75efabc@haskell.org> #9047: Testsuite fails on OS X Mavericks ------------------------------------+--------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Perhaps this is already well-known, but the testsuite utterly fails on Mavericks. Most tests fail because of extra output from clang. Here is a representative: {{{ Actual stderr output differs from expected: --- ./tcfail188.stderr 2014-02-07 15:28:16.000000000 -0500 +++ ./tcfail188.comp.stderr 2014-04-28 14:37:03.000000000 -0400 @@ -0,0 +1,3 @@ +clang: warning: argument unused during compilation: '-fno-stack- protector' +clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' +clang: warning: argument unused during compilation: '-I .' *** unexpected failure for tcfail188(normal) }}} Is this a local setting problem? Or is this something that can be fixed centrally? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 19:00:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 19:00:25 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.0fccf54241fc35ff3f9c8532981e1ee0@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 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 MagnusTherning): I thought I'd make an attempt at verifying this just now, but got stuck already on getting all the sources. First I was told that I had an old {{{time}}} and should run {{{rm libraries/time}}}, which I did. Then I ran into the next issue: {{{ #!sh % ./sync-all -r git://git.haskell.org get -b ghc-7.8 .... == running git submodule update fatal: repository '/startdir/packages/Cabal.git' does not exist Clone of '/startdir/packages/Cabal.git' into submodule path 'librariesCabal' failed git failed: 256 at ./sync-all line 122. }}} I don't really have time to look into this myself, but if I get some guidance I'll be happy to fire off the build while keeping busy with more pressing stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 19:42:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 19:42:56 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.9c9d2880604df1fb18660f1c5c284261@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by goldfire): I don't have a strong opinion here (about the extra tags in `IfaceSyn`). After the type/kind merge, these tags would become visible vs. invisible instead of type vs. kind. The same change is happening in many other places throughout GHC. This actually makes good sense -- in the use case at issue in this ticket, you don't actually care what a thing classifies; you care whether or not it should be printed. Because these two distinctions line up at the moment, it's not worth bothering to separate them. So, by all means go ahead with, e.g., Simon's plan. I'll change it to visible/invisible when I merge. :) And, as for Andrei's offer for help: Thanks. At this point, work is stalled somewhat as I'm racing down the Haskell Symposium deadline (May 12) for two papers I'm working on. But, I'm hoping to have something ready for POPL on July 6 about the type/kind merge. Things are in a bit of a messy state at the moment and it's hard for me to see how to integrate another set of hands, but I'll keep your offer in mind -- I do appreciate it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 19:52:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 19:52:20 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.429c6bc68455927f6dbc3778a77a630b@haskell.org> #8779: Exhaustiveness checks for pattern synonyms --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 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 merijn): * cc: merijn@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 19:52:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 19:52:47 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.1a634e5bee1ca55cce35548964fd9fdb@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Template Haskell | 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 merijn): * cc: merijn@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 20:16:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 20:16:13 -0000 Subject: [GHC] #8070: Use a captcha for trac registrations In-Reply-To: <044.f2a36852e2772074b1987ebd0c5e0ae0@haskell.org> References: <044.f2a36852e2772074b1987ebd0c5e0ae0@haskell.org> Message-ID: <059.75fe3351ad9484fa70f39a6f11a49180@haskell.org> #8070: Use a captcha for trac registrations -------------------------------------+------------------------------------ Reporter: igloo | Owner: hvr Type: task | Status: new Priority: high | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: trac admin Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Fyi, right now we have a simple text-based algebraic expression captcha in place which seems to keep off spammers for now... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 21:49:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 21:49:43 -0000 Subject: [GHC] #9048: armel: evacuate(static): strange closure type 0 Message-ID: <046.ccacb8854bad97b5f58adb6faa140591@haskell.org> #9048: armel: evacuate(static): strange closure type 0 ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I guess I need to document the build failures here, instead of just mentioning them on the mailing list: Building 7.8 on armel on Debian fails with {{{ chmod +x inplace/bin/runghc inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.2 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[2]: *** [compiler/stage2/dll-split.stamp] Aborted make[2]: *** Waiting for unfinished jobs.... make[1]: *** [all] Error 2 }}} Unfortunately, I?m no expert in strange architectures, so I need help from all you arm-lovers out there... Can someone, for starters, confirm this on an arm machine, or is this Debian specific somehow? (Hardening flags have been disabled.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 28 23:48:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Apr 2014 23:48:42 -0000 Subject: [GHC] #9047: Testsuite fails on OS X Mavericks In-Reply-To: <047.0afe1c31b6584b760336c379b75efabc@haskell.org> References: <047.0afe1c31b6584b760336c379b75efabc@haskell.org> Message-ID: <062.1c2069224338a4051a0af325a94c7d59@haskell.org> #9047: Testsuite fails on OS X Mavericks ---------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by goldfire): This also affects Mac OS 10.8.5, for some tests. Specifically, `llvm/should_compile/T{5486,5681,6158,7571}` all fail with errors similar to the original report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 02:13:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 02:13:28 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages Message-ID: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Assertions give great error messages by including file name and line, but they are disabled for optimisation. While there is a compiler flag to turn them on even in presence of optimisation, this is an awkward external way to simply attach a useful error location to something like `error`. It would be great if we could decouple getting the current `srcLoc` from assertions, and making it available for good error messages. It is currently possible to do this using TemplateHaskell (e.g. the `placeholders` package) or `CPP`, but both are inconvenient for technical reasons (such as breaking tooling) and do not enjoy widespread use. It seems a shame that the architecture for annotated error messages is already there, but only available through a mechanism that is disabled for optimisation (or at least "intended" to be disabled for optimisation). Notably, we have the same architecture available for pattern mach failures: {{{ f x | x > 0 = "foo" main = putStrLn (f (-1)) -- gives srcLoc'd pattern match error message }}} {{{ f x | x > 0 = "foo" f _ = error "f needs a positive number" main = putStrLn (f (-1)) -- does not give a srcLoc'd error message }}} It seems non-sensical that your try to write a better error message (here using `error`) yields in fact a less-helpful error message. I completely agree that one can aid bug-fixing by writing globally unique arguments to `error` or using TH, but from an engineering perspective, a little bit of help from the language/compiler side can improve the situation a lot, and in other languages this is acknowledged and used to everybody's benefit. There are some alternatives we might consider, such as * exposing `srcLoc :: String` that gives an `assert`-style location at the lexical position of its occurrence * adding an `error`-like function that behaves like `error` but also prints a source location Arguably `srcLoc :: String` breaks equational reasoning on the ''syntactic'' level, as `let x = srcLoc in (x, x)` and `(srcLoc, srcLoc)` have different values. However, looking at it from a program execution point of view, referential transparency is preserved since once compiled, any function using `srcLoc` will always return the same location. I believe that offering ''some'' kind of improvement over the dreaded `error` or `Prelude: undefined` should be easy to implement, but let's hear what the people who actually know the compiler think about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 03:52:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 03:52:41 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.6c6afe6e7273db2d9f03f719864b173a@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Scott Turner): > In my opinion complex numbers with zero imaginary part should behave like simple real numbers in all such functions. This is a naive understanding of the complex numbers. They are not a plain extension of the real numbers; they are missing the linear ordering. So you can't say that log(0)= -infinity as you do with the real numbers, because there are additional ways in which to approach 0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 03:53:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 03:53:59 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.d84769e6605bcdb3f8fc82b664fb7d15@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Scott Turner): > But wolphramalpha gets ?0, ?infinity or ?indeterminate. which agrees with what I said earlier, > If the real part of y is positive, then the result should be 0. If the real part is negative, then the result should be Infinity. If y is imaginary, the result should be NaN. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 03:57:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 03:57:35 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.79af212bec65a3eb9ebd22441f766473@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Scott Turner): Wolfram Alpha is a good comparison. They're pros. I'm just a math major who remembers his complex analysis pretty well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 04:16:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 04:16:08 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.89c2fb55efda698eddb50ca0d980c050@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Scott Turner): > We can also add special case for raising to 1 to increase accuracy > But I'm not so sure. Special cases are not just messy code; they produce messy values. I've seen an explanation from a numerical analyst that they need a function that's mathematically monotonic, such as log, to be numerically monotonic when computed. It's hard to guarantee smooth computational behavior if special cases are thrown in, in order to gain perfect accuracy. In my opinion it would be better to leave {{{ x ** y = exp (log x * y) }}} in effect, except when x is 0 or infinite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 06:02:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 06:02:59 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.0676846266722d1846bf8cfb24f72fc4@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): Replying to [comment:16 Scott Turner]: > > We can also add special case for raising to 1 to increase accuracy > > But I'm not so sure. > Special cases are not just messy code; they produce messy values. I've seen an explanation from a numerical analyst that they need a function that's mathematically monotonic, such as log, to be numerically monotonic when computed. It's hard to guarantee smooth computational behavior if special cases are thrown in, in order to gain perfect accuracy. > > In my opinion it would be better to leave > {{{ > x ** y = exp (log x * y) > }}} > in effect, except when x is 0 or infinite. Ok. But why we don't want to handle infinity in other functions, such as sqrt, exp, (/) or (*)? Why is (!**) so special? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 07:26:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 07:26:44 -0000 Subject: [GHC] #7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range) In-Reply-To: <046.db8982aae960140182b517f2adaa75d5@haskell.org> References: <046.db8982aae960140182b517f2adaa75d5@haskell.org> Message-ID: <061.435a159832e5ff7541a9a38760e1ec7e@haskell.org> #7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range) ----------------------------------------+------------------------------ Reporter: kgardas | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+------------------------------ Comment (by kgardas): I've attempted to build GHC HEAD as of yesterday (April 28 2014) on the same platform (Debian wheezy/ghc-7.4.1, 32bit PPC) and this time everything went fine. So please close this. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 07:50:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 07:50:15 -0000 Subject: [GHC] #7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range) In-Reply-To: <046.db8982aae960140182b517f2adaa75d5@haskell.org> References: <046.db8982aae960140182b517f2adaa75d5@haskell.org> Message-ID: <061.fe7b55b147669c5b702589591e5dc4f8@haskell.org> #7598: ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range) ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by simonpj): * status: infoneeded => closed * resolution: => fixed Comment: Great! Thanks for testing. Closing as requested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 08:04:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 08:04:43 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.aa0c86328f95d2b021c626ebc8ced6a7@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: augustss (added) Comment: This is a sensible, and long-running feature request. I can't find other tickets about it, which is puzzling, but see [wiki:ExplicitCallStack] for lots of material. I thought that Lennart was muttering about this too, but I can't find the trail. It's possible I may get some time/effort to work in it this summer, but it'd be great to evolve a clear design first. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 08:44:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 08:44:07 -0000 Subject: [GHC] #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 In-Reply-To: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> References: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> Message-ID: <062.bb467b8f051913e4f25c7418db35eef0@haskell.org> #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8866 -------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"ab8bb4893be1896303f30d0f1adff8ea9c2470f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ab8bb4893be1896303f30d0f1adff8ea9c2470f6" Fix scavenge_stack crash (#9045) The new stg_gc_prim_p_ll stack frame was missing an info table. This is a regression since 7.6, because this stuff was part of a cleanup that happened in 7.7. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 08:45:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 08:45:07 -0000 Subject: [GHC] #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 In-Reply-To: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> References: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> Message-ID: <062.84555dfbd02babb950ed67bc8f609a73@haskell.org> #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8866 -------------------------------------+------------------------------------ Changes (by simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 08:46:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 08:46:41 -0000 Subject: [GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" In-Reply-To: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> References: <048.6eff6e35635fc62a1bee0e025c25c0d4@haskell.org> Message-ID: <063.8a27044afd2aa18ba65d582b0e42f5db@haskell.org> #8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.1-rc2 Resolution: fixed | 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 simonmar): * status: infoneeded => closed * resolution: => fixed Comment: I think this is #9045, which I've just fixed in HEAD and will be in 7.8.3. Optimistically closing; please re-open if the problem is in 7.8.3 RC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 09:19:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 09:19:44 -0000 Subject: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate In-Reply-To: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> References: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> Message-ID: <061.e080183466852cab510112c383f986e5@haskell.org> #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4139 -------------------------------------+------------------------------------ Changes (by ulfn): * cc: ulf.norell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 09:47:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 09:47:03 -0000 Subject: [GHC] #9050: Panic when compiling cmm file together with -outputdir Message-ID: <044.0c851e057b25561ca3c3a92b801901b3@haskell.org> #9050: Panic when compiling cmm file together with -outputdir -----------------------------------+--------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- To reproduce: {{{ $ touch test.cmm $ ghc -c test.cmm -outputdir=build ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140428 for x86_64-unknown-linux): hscCmmFile: no_mod }}} The panic is declared in `main/HscMain.hs:hscCompileCmmFile` in place of current module name, but forced in `main/CodeOutput.lhs:outputForeignStubs` by `doesFileExist`. It works without `-outputdir` because in that case module name is not used to create path to stub file, see `main/Finder.lhs:mkStubPaths`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 10:46:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 10:46:33 -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.3ce2d12c31a9cf38f2d2f43dcf4a688b@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: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: closed => new * resolution: fixed => Comment: Whoops, I accidentally closed this prematurely (getEnvironment01 should really be tested under the GHCi way, and when I ran the test, I forgot that. Whoops!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 10:46:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 10:46:50 -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.0fecf203c3dc7ffb409ffdeb1ea9f430@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.10.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: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: 7.8.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 11:01:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 11:01:40 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.69a03919099fcfa529780d82300249df@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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): I've tried with 7.8.2. I get the same performance for `matmultForM_` and `matMultLoop`. I'm not using criterion; just using `+RTS -s`, with `_SIZE = 300`. So I can't reproduce the problem. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 11:06:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 11:06:13 -0000 Subject: [GHC] #9051: Report heap profile data in eventlog Message-ID: <045.3c63a8138228d719761c7f929bb060c2@haskell.org> #9051: Report heap profile data in eventlog ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It would be useful if heap profile data could be reported in the eventlog (either by assigning samples with IDs and recording the sample in the eventlog, or putting the entire profile information in the eventlog). This would make it easier to correlate heap profile data with other events reported by the RTS. It may be hard to stuff the entire sample in the eventlog because the sample is arbitrary size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 11:31:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 11:31:06 -0000 Subject: [GHC] #9052: Support a "stable heap" which doesn't get garbage collected Message-ID: <045.cef633f00b20a59333331a11354e10ec@haskell.org> #9052: Support a "stable heap" which doesn't get garbage collected ----------------------------------------------+---------------------------- Reporter: ezyang | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: 7.9 Architecture: Unknown/Multiple | Operating System: Difficulty: Moderate (less than a day) | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: | None/Unknown | Test Case: | Blocking: ----------------------------------------------+---------------------------- Simon Marlow was explaining the concept on IRC. The problem we're trying to solve is you might have some very long-lived pointer data-structures, and you don't want to waste time traversing this structure on a major GC when you know that it is still going to be alive. Here's the basic idea: 1. We have a new generation on the heap called the 'stable heap' (along- side the nursery, gen0, gen1, etc). By default, no objects are automatically promoted from the old gen to the stable heap. 2. A user can request an object be moved to the stable heap, creating a stable pointer which points to the object. 3. During garbage collection, all blocks in the stable heap are always considered reachable. We don't include the stable pointers in the root set (so we don't trace the stable heap), however, write barriers are processed as usual, and we promote any objects pointed to by the stable heap to the stable heap. 4. Users manually request the stable heap to be garbage-collected, usually after deallocating stable pointers. In short, the stable heap is just another generation, but one which (1) is only collected by user request, and (2) never receives objects from automatic promotion. This project fits in very nicely with the existing GC infrastructure, so if you understand how everything is laid out this should be reasonably easy to implement. Could be a good ticket for someone who wants to get their hands dirty with the GC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 11:33:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 11:33:21 -0000 Subject: [GHC] #8933: process007: internal error: checkStackFrame: weird activation record found on stack In-Reply-To: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> References: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> Message-ID: <062.15d17eeb99238fc276cb73ebd7d37dab@haskell.org> #8933: process007: internal error: checkStackFrame: weird activation record found on stack ----------------------------------+------------------------------------ Reporter: trommler | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: ppc Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: process007 | Blocked By: Blocking: 8819 | Related Tickets: #8819 ----------------------------------+------------------------------------ Comment (by trommler): ghc 7.8.2 unregisterised on x86_64 Linux: {{{ $ make TEST=process007 [...] Unexpected results from: TEST="process007" OVERALL SUMMARY for test run started at Tue Apr 29 13:31:11 2014 CEST 0:00:14 spent to go through 3918 total tests, which gave rise to 15288 test cases, of which 15280 were skipped 0 had missing libraries 3 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 5 unexpected failures Unexpected failures: ../../libraries/process/tests process007 [bad exit code] (normal,hpc,threaded1,dyn,optllvm) make[1]: Leaving directory `/home/trp/research/ghc- unreg/ghc-7.8.2/testsuite/tests' }}} I'll post ppc64 later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 12:35:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 12:35:36 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.53c92f542e74e974e682afa87d1dc44c@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ 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 daniel.is.fischer): Replying to [comment:16 simonpj]: > I've tried with 7.8.2. I get the same performance for `matmultForM_` and `matMultLoop`. Are you compiling with `-O`? You need `-O2` for a significant difference to appear (with only `-O`, both versions are slow). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 12:52:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 12:52:55 -0000 Subject: [GHC] #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 In-Reply-To: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> References: <047.0aa4066036390bb00a4e5f6d7de13d4a@haskell.org> Message-ID: <062.6fd07b345d17bbedb7c52c167abc749f@haskell.org> #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8866 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 15:12:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 15:12:06 -0000 Subject: [GHC] #9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory] Message-ID: <048.1430731adc1d95572db5390549fbba3c@haskell.org> #9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory] -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: smartos illumos | Operating System: Solaris lndir sdist | Type of failure: Building GHC Architecture: Unknown/Multiple | failed Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- It appears that source for lndir was intentionally included in utils and customized to handle .git directories: http://git.haskell.org/ghc.git/blobdiff/c629bd1539b1865cc28ce053234595e7aeb8a5c0..8023014ecf192381ffba4b60a3dd21630e5c1d18:/utils/lndir/lndir.c This ignoring of .git directories has been in the upstream lndir.c since 2009: http://cgit.freedesktop.org/xorg/util/lndir/tree/lndir.c However, lndir is not installed by default (on Ubuntu or SmartOS) and is not listed in the tools required to build: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools It does not appear to be built during the sync, boot, or make steps of a GHC build. Here is an excerpt: {{{ /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] ghc.mk:1117: recipe for target 'sdist-ghc-prep' failed gmake[1]: *** [sdist-ghc-prep] Error 127 Makefile:64: recipe for target 'sdist' failed gmake: *** [sdist] Error 2 }}} Here is a detailed log: http://haskell.inf.elte.hu/builders/smartos-x86_64-head/19/16.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 15:12:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 15:12:36 -0000 Subject: [GHC] #9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory] In-Reply-To: <048.1430731adc1d95572db5390549fbba3c@haskell.org> References: <048.1430731adc1d95572db5390549fbba3c@haskell.org> Message-ID: <063.8aab6fbccaf2fd8f766d18dbc1a9442a@haskell.org> #9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory] -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Resolution: | Keywords: smartos illumos Operating System: Solaris | lndir sdist Type of failure: Building GHC | Architecture: Unknown/Multiple failed | Difficulty: Easy (less than 1 Test Case: | hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by AlainODea): Based on my investigation lndir should be listed in the tools required to build and should be removed from the source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 16:07:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 16:07:12 -0000 Subject: [GHC] #9054: runghc- does not call ghc of the same version Message-ID: <048.09116779ce49b45664b7ce81fecc6578@haskell.org> #9054: runghc- does not call ghc of the same version ------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I ran runghc-7.6.3, it actually executed "/usr/local/bin/ghc" which points to ghc-7.8.2. The offending line is inside the runghc- script: {{{ exec "$executablename" -f "$bindir/ghc" ${1+"$@"} }}} Which should be: {{{ exec "$executablename" -f "$bindir/ghc-" ${1+"$@"} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 17:40:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 17:40:38 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.9b29b33930f5edf986f7e87f10804fa7@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Replying to [comment:2 trommler]: > I tried the test program on openSUSE 12.3: > {{{ > environ = 0x601060 > dlsym(deflt, "environ") = 0x601060 > dlsym("libgmp", "environ") = 0x601060 > dlsym("libpthread", "environ") = 0x601060 > }}} > Here is my libgmp: > {{{ > ls /usr/lib64/libgmp.so* > /usr/lib64/libgmp.so /usr/lib64/libgmp.so.10 /usr/lib64/libgmp.so.10.0.5 > }}} > > IIRC POSIX.1 (but not C!) reserves variable {{{environ}}}. So I'd say it is a bug in Ubuntu's libgmp. The original distro I encountered the problem on was CentOS. I don't think it is to do with gmp specifically, IIRC there were other libraries that cause the behaviour too (but I'd need to go back and check again). My partial theory is that because `environ` is a symbol with R_COPY relocation, the linker is confused and has returned the original location (before the contents were copied and the symbol relocated). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 19:35:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 19:35:11 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.d7544975d41425689060d4a652e048ec@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Tarrasch Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 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 Simon Marlow ): In [changeset:"43b3bab38eafef8c02a09fb4ff1e757f5cba6073/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="43b3bab38eafef8c02a09fb4ff1e757f5cba6073" Rts: Consistently use StgWord for sizes of bitmaps A long debate is in issue #8742, but the main motivation is that this allows for applying a patch to reuse the function scavenge_small_bitmap without changing the .o-file output. Similarly, I changed the types in rts/sm/Compact.c, so I can create a STATIC_INLINE function for the redundant code block: while (size > 0) { if ((bitmap & 1) == 0) { thread((StgClosure **)p); } p++; bitmap = bitmap >> 1; size--; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 19:35:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 19:35:11 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.c2717f835e74b2443bcfac6e461710af@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Tarrasch Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 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 Simon Marlow ): In [changeset:"05fcc3331622995015ccba17ae333b9a0fc9bb77/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="05fcc3331622995015ccba17ae333b9a0fc9bb77" Rts: Reuse scavenge_small_bitmap (#8742) The function was inlined at two places already. And the function is having the STATIC_INLINE annotation, so the assembly output should. be the same. To convince myself, I did diff the output of the object files before and after the patch and they matched on my 64-bit Ubuntu 13.10 machine, running gcc 4.8.1-10ubuntu9. Also, I had to move scavenge_small_bitmap up a bit since it's not in any .h-file. While I was at it, I also applied the analogous patch for Compact.c. Though I had to write `thread_small_bitmap` instead of just moving it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 19:45:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 19:45:10 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.3620c263a539cc2b291c9335cb2093ee@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): OK, well, it's not a massive deal. It seems a bit odd to be futzing with `IfaceSyn` to make it display more nicely, and if it got out of hand I'd think again. But for now, I suggest you go ahead with the `IfaceTcArgs` approach I outlined above. OK? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 20:16:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 20:16:01 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.a74160760a6cbda334553c58faf935de@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Tarrasch Type: task | Status: closed Priority: lowest | Milestone: 7.10.1 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 simonmar): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 20:39:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 20:39:40 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.aa33475b993d5344bc7b8a799fbe0373@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by refold): Replying to [comment:1 simonpj]: > I thought that Lennart was muttering about this too, but I can't find the trail. I think you're referring to these posts: http://augustss.blogspot.se/2014/04/a-small-haskell-extension.html http://augustss.blogspot.se/2014/04/haskell-error-reporting-with- locations_5.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 20:49:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 20:49:10 -0000 Subject: [GHC] #9055: unregisterised build fails with: globalRegMaybe not defined for this platform Message-ID: <047.895e86d82de4bb687806c7f173056b25@haskell.org> #9055: unregisterised build fails with: globalRegMaybe not defined for this platform -----------------------------------+--------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Building HEAD fails with: {{{ make[1]: *** [rts/dist/build/Updates.o] Error 1 ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140429 for powerpc64-unknown-linux): globalRegMaybe not defined for this platform }}} on Linux powerpc64 and x86_64 (unregisterised). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 20:58:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 20:58:56 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.60cdfd6bf56ff3465d24b6e439fee58d@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dagit): I haven't tested if I have the crash on my system, but suspect you're seeing something to do with weak symbols. On my system, Fedora 19, I see that glibc defines environ as a weak symbol and gives it the same address that your libgmp check reports. I modified your C program slightly so that it takes the paths in `argv[1]` and `argv[2]`: {{{ $ ./check-environ /usr/lib64/libgmp.so /usr/lib64/libpthread.so environ = 0x601058 dlsym(deflt, "environ") = 0x601058 dlsym("libgmp", "environ") = 0x31e45bd508 dlsym("libpthread", "environ") = 0x601058 }}} My libgmp doesn't define environ so it must find it in libc, and indeed: {{{ $ readelf -Wa /usr/lib64/libc.so.6 | grep environ 00000031e45b9dd8 0000011900000006 R_X86_64_GLOB_DAT 00000031e45bd508 _environ + 0 00000031e45b9ea0 0000050000000006 R_X86_64_GLOB_DAT 00000031e45bd508 __environ + 0 281: 00000031e45bd508 8 OBJECT WEAK DEFAULT 33 _environ@@GLIBC_2.2.5 956: 00000031e45bd508 8 OBJECT WEAK DEFAULT 33 environ@@GLIBC_2.2.5 1280: 00000031e45bd508 8 OBJECT GLOBAL DEFAULT 33 __environ@@GLIBC_2.2.5 349: 00000031e45bbe70 8 OBJECT LOCAL DEFAULT 33 last_environ 1813: 0000000000000000 0 FILE LOCAL DEFAULT ABS environ.c 4539: 00000031e4238a10 1122 FUNC LOCAL DEFAULT 12 __add_to_environ 5707: 00000031e45bd508 8 OBJECT WEAK DEFAULT 33 _environ 6374: 00000031e45bd508 8 OBJECT GLOBAL DEFAULT 33 __environ 6483: 00000031e45bd508 8 OBJECT WEAK DEFAULT 33 environ }}} I suspect that the way you're searching for the symbol needs to look for a (the?) strong binding first. I hope that helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 21:10:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 21:10:34 -0000 Subject: [GHC] #8963: GeneralizedNewtypeDeriving unusable on associated types In-Reply-To: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> References: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> Message-ID: <062.664fff7b3a9389c5eb7ba2fe256d9452@haskell.org> #8963: GeneralizedNewtypeDeriving unusable on associated types -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: Type: bug | Status: merge 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: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 21:10:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 21:10:48 -0000 Subject: [GHC] #8963: GeneralizedNewtypeDeriving unusable on associated types In-Reply-To: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> References: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> Message-ID: <062.1312da8612f0fdfa16509da12ab0d5a7@haskell.org> #8963: GeneralizedNewtypeDeriving unusable on associated types -------------------------------------+------------------------------------ Reporter: mojojojo | 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: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 21:11:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 21:11:05 -0000 Subject: [GHC] #9025: Core Lint warning with -O (Demand type has 4 arguments ...) In-Reply-To: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> References: <044.55d9652346aafe7e4537a44a027744c5@haskell.org> Message-ID: <059.bedf1247658b04a383483b19a518cc4a@haskell.org> #9025: Core Lint warning with -O (Demand type has 4 arguments ...) -------------------------------------+------------------------------------ Reporter: conal | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 21:11:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 21:11:15 -0000 Subject: [GHC] #9039: Annotation reification from TH is not looking into HPT In-Reply-To: <044.cc8f48625f71a576e5f2b834d07d0d9e@haskell.org> References: <044.cc8f48625f71a576e5f2b834d07d0d9e@haskell.org> Message-ID: <059.cc0f0e2f698792f0242c7bef4d702631@haskell.org> #9039: Annotation reification from TH is not looking into HPT -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Moderate (less at runtime | than a day) Test Case: annth_make | Blocked By: annth_compunits | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 21:12:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 21:12:10 -0000 Subject: [GHC] #8963: GeneralizedNewtypeDeriving unusable on associated types In-Reply-To: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> References: <047.ce8d7ef5a28995c6031f4e5721b14847@haskell.org> Message-ID: <062.cffc00374d56b579b512e8339ec107b4@haskell.org> #8963: GeneralizedNewtypeDeriving unusable on associated types -------------------------------------+------------------------------------ Reporter: mojojojo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 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): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 21:15:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 21:15:17 -0000 Subject: [GHC] #9055: unregisterised build fails with: globalRegMaybe not defined for this platform In-Reply-To: <047.895e86d82de4bb687806c7f173056b25@haskell.org> References: <047.895e86d82de4bb687806c7f173056b25@haskell.org> Message-ID: <062.9d62b2e2ee98dab93ca2ba1246843f1d@haskell.org> #9055: unregisterised build fails with: globalRegMaybe not defined for this platform ---------------------------------------+----------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 trommler): I reverted changeset:83a003f and GHC does not panic anymore. I only tried that on x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 21:37:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 21:37:27 -0000 Subject: [GHC] #9002: bus error on sparc in ffi call In-Reply-To: <046.0f1e0eef29c036a6cc921114c21e878a@haskell.org> References: <046.0f1e0eef29c036a6cc921114c21e878a@haskell.org> Message-ID: <061.ec096b5907b98d36d1a1eb6d2769b74e@haskell.org> #9002: bus error on sparc in ffi call ----------------------------------+--------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: sparc Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: Seems to be a problem in the C code, and not in ffi or GHC (https://github.com/vincenthz/hs-cryptohash/issues/24). Sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 21:44:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 21:44:37 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.d9e9fa7b897df497fcc1a8dedc1360de@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dagit): I just realized my previous reply probably leaves people wondering: Since libpthread also DOES NOT define environ why does it give the right address? The difference is that libpthread depends on ld-linux.so as a shared object dependency (grep the readelf -Wa output for `NEEDED`) and ld- linux.so defines a `LOCAL` symbol for environ. As I understand it, that means the dynamic linker thinks libpthread defines environ as `LOCAL` (so it goes to look for a different definition and ends up with the right one). For libgmp it looks in libc.so and finds a `WEAK` definition and uses it because there is no other `GLOBAL` definition. To help demonstrate this, consider this example. On my system, libz.so has dependencies similar to libgmp.so: {{{ $ readelf -Wa /usr/lib64/libgmp.so.10 | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] $ readelf -Wa /usr/lib64/libz.so.1 | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] }}} And look at this: {{{ $ ./check-environ /usr/lib64/libgmp.so /usr/lib64/libz.so.1 environ = 0x601058 dlsym(deflt, "environ") = 0x601058 dlsym("libgmp", "environ") = 0x31e45bd508 dlsym("libpthread", "environ") = 0x31e45bd508 }}} I'm still fuzzy on some of the details, but it seems that `WEAK` and `LOCAL` mean very different things to the dynamic linker. `WEAK` is the same as `GLOBAL` but the link priority is lower, while `LOCAL` means the symbol should not be exported. As far as I can tell, when it finds `LOCAL` it continues the search whereas with `WEAK` it stops earlier because technically it has found an exported symbol. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 21:54:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 21:54:50 -0000 Subject: [GHC] #7730: :info and polykinds In-Reply-To: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> References: <047.d9598f299af5548b87d2fb8d98b00c27@haskell.org> Message-ID: <062.8a6643e90873e698103aa5af02bc8419@haskell.org> #7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): Yes, I'll whip up a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 23:19:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 23:19:21 -0000 Subject: [GHC] #1831: reify never provides the declaration of variables In-Reply-To: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> References: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> Message-ID: <059.ba7d178e19a6044d189acb0479c5ad13@haskell.org> #1831: reify never provides the declaration of variables -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Template Haskell | 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 blarsen): * cc: brad.larsen@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 29 23:47:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Apr 2014 23:47:04 -0000 Subject: [GHC] #9056: --make paths are not deduplicated Message-ID: <054.6d9311fc6ac4a797c0df6e46e05c1bcb@haskell.org> #9056: --make paths are not deduplicated -------------------------+------------------------------------------------- Reporter: | Owner: evincarofautumn | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I had a build script with an accidental duplicate dependency, which caused GHC to be run like so: {{{ ghc --make Main.hs Main.hs }}} This results in a spurious error from `GhcMake.checkDuplicates`: {{{ : module ?main:Main? is defined in multiple files: Main.hs Main.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 00:29:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 00:29:03 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.534e5733b7c188653a1821d66cc03b09@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jwlato): * cc: jwlato@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 01:01:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 01:01:53 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.c14927e36496d9a2539bd8a9c0c8e809@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by pumpkin): Thanks! It was a lucky (or unlucky) test case. Good point about the `ADD` vs. `ADC`, and I'm not sure. I don't see myself having much time in the near future to dig in but if nobody gets to it first in the next two or three weeks I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 01:40:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 01:40:34 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.6d39568aea7810b7e6ac2b59a8b456ab@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science 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 Wed Apr 30 02:57:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 02:57:18 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.b0d74f3d5ed0e35444322c7deb6a204f@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Scott Turner): I don't know that (!**) is more special. Maybe we are talking about it because it has the rule {{{ x ** 0 == 1 }}} which is peculiarly effective. It does battle with another rule {{{ 0 ** x == 0 }}} and in the judgement of most numerical analysis, it wins the fight. I think the reason people aren't diving in to address how all the other operators handle complex infinities is that it's very ''complex''. Your patch handles a few cases well, but it doesn't come near to handling them all. For example, it doesn't take care of {{{ (infinity:+infinity)*(infinity:+infinity) == (NaN:+infinity) }}} which is poor because the result should be a plain infinite value. The same kind of thing can happen, even if one of the operands is finite. Then there are cases in which there's an intermediate overflow but the best result is not infinite. That's because {{{ (x:+y) * (x':+y') = (x*x'-y*y') :+ (x*y'+y*x') }}} subtracts after multiplying. The intermediate x*x' can be unrepresentable, while x*x'-y*y' is representable. It's all a lot of fun. It would be nice work if someone would pay us for doing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 03:20:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 03:20:24 -0000 Subject: [GHC] #9013: plusWord2# is buggy In-Reply-To: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> References: <046.fcf7ed4143d86fd58d730fa15e6146cd@haskell.org> Message-ID: <061.25f39ec1c5dcaffa88c7f349db3bd322@haskell.org> #9013: plusWord2# is buggy -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Simon: `MO_Add2` is translated to an `ADD` (which is expected to either set or clear the carry flag as appropriate) followed by an `ADC`. Printing the `ADD` as (in this case) `dec` rather than `add` loses the effect on the carry flag, so the subsequent `ADC` will just use whatever garbage happens to be in the carry flag. Like Simon, I'm not totally thrilled with the organization of the code here, but one simple fix would be to add an `ADD'` instruction which means the same as `ADD` except it indicates that the side effect of setting the carry flag is important. Then the pretty printer can produce `dec` for an `ADD` of `-1` but not for an `ADD'` of `-1`. GHC doesn't expose the carry flag to Haskell directly so we would only need to use `ADD'` in the translation of `MO_Add2` and other similar operations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 04:08:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 04:08:49 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.a96034500d135d70ea29ede9e696d254@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Rocket Science Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by akio): * cc: tkn.akio@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 07:06:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 07:06:04 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.d3ee57deadebe1d2798acb112e5df1cf@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): Replying to [comment:18 Scott Turner]: > It's all a lot of fun. It would be nice work if someone would pay us for doing it. I can not disagree with you. It's very interesting even for free, at least for now because it's my first try to contribute to open source project. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 07:12:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 07:12:34 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.cea36bb53212e5027a4d72acc3f028df@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): Replying to [comment:18 Scott Turner]: > Maybe we are talking about it because it has the rule > {{{ > x ** 0 == 1 > }}} I think it is completely safe to define: {{{ _ ** (0:+0) = 1 :+ 0 }}} Because {{{exp $ log any_finite_number * (0:+0)}}} always equals {{{1:+0}}}. The only difference is for NaN, but {{{NaN**0 :: Double}}} equals {{{1}}} too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 08:33:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 08:33:27 -0000 Subject: [GHC] #9055: unregisterised build fails with: globalRegMaybe not defined for this platform In-Reply-To: <047.895e86d82de4bb687806c7f173056b25@haskell.org> References: <047.895e86d82de4bb687806c7f173056b25@haskell.org> Message-ID: <062.911fe5cd390fb35bf134bcd2aa1dc482@haskell.org> #9055: unregisterised build fails with: globalRegMaybe not defined for this platform ---------------------------------------+----------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 trommler): * owner: => trommler Comment: Fix is coming. I am validating right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 09:04:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 09:04:54 -0000 Subject: =?utf-8?q?=5BGHC=5D_=239057=3A_Remove_/usr/bin/=E2=80=A6_referen?= =?utf-8?q?ces?= Message-ID: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> #9057: Remove /usr/bin/? references -------------------------------------------+------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- The use of /usr/bin/perl in sync-all makes it difficult to work with on distros which don't store binaries in /usr/bin, such as NixOS. A more portable solution would be to use /usr/bin/env perl. It'd be very nice if someone turned such shebangs to use env rather than direct reference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 09:23:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 09:23:33 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MDU3OiBSZW1vdmUgL3Vzci9iaW4v4oCmIHJl?= =?utf-8?q?ferences?= In-Reply-To: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> References: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> Message-ID: <062.faf221fb07fbbc273464d0b3dab12cc0@haskell.org> #9057: Remove /usr/bin/? references -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Joachim Breitner ): In [changeset:"34db5ccf52ec2a1b5e953c282d0c52a7fc82c02a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="34db5ccf52ec2a1b5e953c282d0c52a7fc82c02a" Replace all #!/usr/bin/perl with #!/usr/bin/env perl As suggested in #9057. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 09:23:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 09:23:47 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MDU3OiBSZW1vdmUgL3Vzci9iaW4v4oCmIHJl?= =?utf-8?q?ferences?= In-Reply-To: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> References: <047.a3a797cb87f77ebce2b007895bceba64@haskell.org> Message-ID: <062.b230bb05631930470da95d195f40ddd7@haskell.org> #9057: Remove /usr/bin/? references -------------------------------+------------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Quite right; fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 09:53:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 09:53:46 -0000 Subject: [GHC] #9055: unregisterised build fails with: globalRegMaybe not defined for this platform In-Reply-To: <047.895e86d82de4bb687806c7f173056b25@haskell.org> References: <047.895e86d82de4bb687806c7f173056b25@haskell.org> Message-ID: <062.02b616f5f83f1cd029369ff2653f72d4@haskell.org> #9055: unregisterised build fails with: globalRegMaybe not defined for this platform ---------------------------------------+----------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 trommler): * status: new => patch Comment: Validated attached patch on x86_64. Will do powerpc64 tonight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 09:53:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 09:53:57 -0000 Subject: [GHC] #9055: unregisterised build fails with: globalRegMaybe not defined for this platform In-Reply-To: <047.895e86d82de4bb687806c7f173056b25@haskell.org> References: <047.895e86d82de4bb687806c7f173056b25@haskell.org> Message-ID: <062.ec95ade7d473259fb8c2e28d52a92b81@haskell.org> #9055: unregisterised build fails with: globalRegMaybe not defined for this platform ---------------------------------------+----------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 trommler): * owner: trommler => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 09:58:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 09:58:18 -0000 Subject: [GHC] #8933: process007: internal error: checkStackFrame: weird activation record found on stack In-Reply-To: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> References: <047.eb1d0af3a88bd3a6aaa02c5018d9d701@haskell.org> Message-ID: <062.66e4ea61a8236fde015d78d12647da42@haskell.org> #8933: process007: internal error: checkStackFrame: weird activation record found on stack ----------------------------------+------------------------------------ Reporter: trommler | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: ppc Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: process007 | Blocked By: Blocking: 8819 | Related Tickets: #8819 ----------------------------------+------------------------------------ Comment (by trommler): You probably wanted me to check with HEAD, sorry. On x86_64 (unregisterised) process007 passes in HEAD plus my patch for #9055. I will check powerpc64 tonight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 10:00:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 10:00:40 -0000 Subject: [GHC] #9055: unregisterised build fails with: globalRegMaybe not defined for this platform In-Reply-To: <047.895e86d82de4bb687806c7f173056b25@haskell.org> References: <047.895e86d82de4bb687806c7f173056b25@haskell.org> Message-ID: <062.12123c894024cb5331ec563f26c5fe46@haskell.org> #9055: unregisterised build fails with: globalRegMaybe not defined for this platform ---------------------------------------+----------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 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 trommler): * milestone: => 7.10.1 Comment: We should merge this into 7.8.3 if changeset:83a003f goes in 7.8.3. For now I'm setting milestone to 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 10:06:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 10:06:53 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.542dd0896cf11e9a7beba455754e1d94@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Scott Turner): > NaN!**0 :: Double equals 1 too. See [http://wikipedia.org/wiki/NaN#Signaling_NaN] for an exception to that. The same Wikipedia article has interesting things to say about 0!**0 and infinity!**0 also. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 10:21:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 10:21:11 -0000 Subject: [GHC] #9058: System.IO.openTempFile does not scale Message-ID: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> #9058: System.IO.openTempFile does not scale ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In search of a bug in darcs http://bugs.darcs.net/issue2364 i've notice very bad property of openTempFile: it's pattern is very predictable and has O(n^2) of already created temp files. Predictability allows very fun bugs survive in buggy programs, like: {{{ thread1: (fn, fh) <- openTempFile "." "hello" renameFile fn "something" -- some time after when (some_rare_buggy_condition) $ -- oops, reused temp name, but too late, other thread killed it writeFileFile fn thread2: (fn, fh) <- openTempFile "." "hello" workWithFn fn -- nobody should touch it, right? }}} It's _very_ hard to debug data corruption when all temp files are named "foo${pid}" and sometimes "foo${pid+1}". And more serious bug: the more threads you have trying to create similar temps performance drops significantly: Attached program shows the following numbers: {{{ $ time ./bench-temps same 2000 real 0m2.795s user 0m1.516s sys 0m1.190s $ time ./bench-temps diff 2000 real 0m0.161s user 0m0.043s sys 0m0.115s }}} It's O(N^2) growing open() storm. https://github.com/ghc/ghc/blob/master/libraries/base/System/IO.hs#L465 {{{ FileExists -> findTempName (x + 1) }}} This is the source of the problem. I'd suggest always using random name for it. For portability reasons I suggest adding at least insecure random '''rand()''' value from C library. That way we will succeed in opening temp file at the first attempt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 10:33:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 10:33:00 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.6ef84f95b80233ae686a2c2817d3b442@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): Replying to [comment:21 Scott Turner]: > > NaN!**0 :: Double equals 1 too. > See [http://wikipedia.org/wiki/NaN#Signaling_NaN] for an exception to that. The same Wikipedia article has interesting things to say about 0!**0 and infinity!**0 also. Interesting. It says: > The 2008 version of the IEEE 754 standard says that pow(1,qNaN) and pow(qNaN,0) should both return 1 since they return 1 whatever else is used instead of quiet NaN. Should we add another definition? {{{ (1:+0) ** _ = 1:+0 }}} To fix this: {{{ Prelude Data.Complex> 1 ** (0/0) :: Double 1.0 Prelude Data.Complex> 1 ** (0/0) :: Complex Double NaN :+ NaN }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 11:13:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 11:13:37 -0000 Subject: [GHC] #9058: System.IO.openTempFile does not scale In-Reply-To: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> References: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> Message-ID: <060.f8d69aa0a25a0ce6b0b3a6b7624639f0@haskell.org> #9058: System.IO.openTempFile does not scale -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): Here is one simple solution. it basically changes prefix ++ getpid() ++ suffix for prefix ++ rand() ++ rand() ++ suffix Technically rand() might be thread-unsafe (but not on glibc, there random_r() is used silently) but i don't think it's a troblem at all. Otherwise we could use time-based timestamp, but picking precise time source (to use it more, than 1000 times a second) might be a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 11:17:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 11:17:39 -0000 Subject: [GHC] #8539: Data.Complex shouldn't use default implementation of (**) In-Reply-To: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> References: <052.eaf7f8021336085133b73887b1d1ced3@haskell.org> Message-ID: <067.62c7c9aff4f6775be282ec8293eb159d@haskell.org> #8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by yalas): Other floating functions seems to be ok (or almost ok) with infinity: {{{ Prelude Data.Complex> sqrt $ 1/0 :+ 0 Infinity :+ 0.0 Prelude Data.Complex> sqrt $ 1/0 :+ 1/0 Infinity :+ NaN Prelude Data.Complex> sqrt $ (-1/0) :+ 0 0.0 :+ Infinity Prelude Data.Complex> sqrt $ (-1/0) :+ (-1/0) NaN :+ (-Infinity) Prelude Data.Complex> log $ 1/0 :+ 0 Infinity :+ 0.0 Prelude Data.Complex> log $ 1/0 :+ 1/0 Infinity :+ NaN Prelude Data.Complex> log $ (-1/0) :+ 0 Infinity :+ 3.141592653589793 Prelude Data.Complex> log $ 0 :+ 0 (-Infinity) :+ 0.0 Prelude Data.Complex> log $ (-1/0) :+ (-1/0) Infinity :+ NaN Prelude Data.Complex> exp $ 1/0 :+ 1 Infinity :+ Infinity Prelude Data.Complex> exp $ 1/0 :+ 0 Infinity :+ NaN Prelude Data.Complex> exp $ (-1/0) :+ 0 0.0 :+ 0.0 }}} But (!**) can not raise to infinity: {{{ Prelude Data.Complex> 2 ** (1/0 :+ 1) NaN :+ NaN Prelude Data.Complex> 2 ** (1/0 :+ 0) NaN :+ NaN Prelude Data.Complex> 2 ** ((-1/0) :+ 0) NaN :+ NaN }}} Is it need to be fixed too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 13:12:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 13:12:03 -0000 Subject: [GHC] #9058: System.IO.openTempFile does not scale In-Reply-To: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> References: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> Message-ID: <060.eb305dce823cf34a9d7d1650a486ccef@haskell.org> #9058: System.IO.openTempFile does not scale -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by slyfox): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 13:24:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 13:24:07 -0000 Subject: [GHC] #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' In-Reply-To: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> References: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> Message-ID: <060.a11652e0836fbd92e6c0de3bf31eff52@haskell.org> #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' -------------------------------------+------------------------------------ Reporter: slyfox | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by slyfox): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 13:25:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 13:25:05 -0000 Subject: [GHC] #8787: compiler/ghc.mk: restore GhcHcOpts variable handling In-Reply-To: <045.af6493130ade2a702cc9b0745af091cb@haskell.org> References: <045.af6493130ade2a702cc9b0745af091cb@haskell.org> Message-ID: <060.2b0b30a8654436d1f6418571ff7ad273@haskell.org> #8787: compiler/ghc.mk: restore GhcHcOpts variable handling -------------------------------------+------------------------------------ Reporter: slyfox | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by slyfox): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 13:56:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 13:56:54 -0000 Subject: [GHC] #9059: Excessive space usage while generating code for fractional literals with big exponents Message-ID: <049.6d8f94befa1b5f7c36b68d142aab3d6d@haskell.org> #9059: Excessive space usage while generating code for fractional literals with big exponents ------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Generating (byte-)code for fractional literals with big exponents causes excessive space usage: {{{ $ ghci -ddump-bcos 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. Prelude> let r=1e1000 :: Rational ==================== Proto-BCOs ==================== ProtoBCO ExprTopLevel_E0#0 []: let sat_so4 = ... in ... bitmap: 0 [] ALLOC_AP 0 PUSH_BCO ProtoBCO sat_so4#0 []: let sat_snX = ... in ... bitmap: 0 [] PUSH_UBX (1) 1 PACK GHC.Integer.Type.S# 1 ALLOC_AP 0 PUSH_BCO ProtoBCO sat_snY#0 []: let sat_siH = ... in ... bitmap: 0 [] STKCHECK 544 PUSH_UBX (1) 30 PACK GHC.Types.I# 1 PUSH_G GHC.Types.[] PUSH_L 1 PACK : 2 PUSH_UBX (1) 953884573 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1777164331 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1665817172 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1937337765 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 799142572 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1439062260 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1049546550 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 580758741 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 139570364 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 ... }}} Increasing the exponent to say a 1000000 will quickly fill up the memory of my machine. A similar problem occurs while compiling: !BigExponentBug.hs: {{{ module BigExponentBug (r) where r = 1e100 :: Rational }}} {{{ ghc --make BigExponentBug.hs -ddump-simpl [1 of 1] Compiling BigExponentBug ( BigExponentBug.hs, BigExponentBug.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 9, types: 5, coercions: 0} BigExponentBug.r :: GHC.Real.Rational [GblId] BigExponentBug.r = GHC.Real.fromRational @ GHC.Real.Rational (GHC.Real.$fFractionalRatio @ GHC.Integer.Type.Integer (GHC.Real.$fNumRatio @ GHC.Integer.Type.Integer GHC.Real.$fIntegralInteger) GHC.Real.$fIntegralInteger) (GHC.Real.:% @ GHC.Integer.Type.Integer (__integer 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000) (__integer 1)) }}} Again increasing the exponent to 1000000 quickly invokes the OOM killer on my machine. P.S. This bug was discovered while fixing a [https://github.com/bos/aeson/issues/198 related bug] in `aeson`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 15:10:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 15:10:22 -0000 Subject: [GHC] #9059: Excessive space usage while generating code for fractional literals with big exponents In-Reply-To: <049.6d8f94befa1b5f7c36b68d142aab3d6d@haskell.org> References: <049.6d8f94befa1b5f7c36b68d142aab3d6d@haskell.org> Message-ID: <064.81f8530b7e257a9c8876910fc28446a7@haskell.org> #9059: Excessive space usage while generating code for fractional literals with big exponents -------------------------------------+------------------------------------ Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by basvandijk): #5688 is related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 19:25:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 19:25:54 -0000 Subject: [GHC] #9060: `cabal` linking error with GHC 7.8.2 Message-ID: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> #9060: `cabal` linking error with GHC 7.8.2 ----------------------------------+-------------------------- Reporter: pseudonom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+-------------------------- First reported on [https://github.com/haskell/cabal/issues/1830 GitHub]. Trying {{{ rm -r .ghc .cabal cabal update cabal install cabal-install # Update from 1.16.0.2 to 1.20.0.0 cabal install polyparse }}} with GHC 7.8.2 throws the following error: {{{ [18 of 18] Compiling Text.ParserCombinators.HuttonMeijer ( src/Text/ParserCombinators/HuttonMeijer.hs, dist/build/Text/ParserCombinators/HuttonMeijer.o ) src/Text/ParserCombinators/HuttonMeijer.hs:53:10: Warning: ?Parser? is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. src/Text/ParserCombinators/HuttonMeijer.hs:63:10: Warning: ?Parser? is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. Linking... /usr/bin/ar -r dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a dist/build/Text/ParserCombinators/HuttonMeijer.o dist/build/Text/ParserCombinators/HuttonMeijerWallace.o dist/build/Text/ParserCombinators/Poly.o dist/build/Text/ParserCombinators/Poly/Base.o dist/build/Text/ParserCombinators/Poly/Result.o dist/build/Text/ParserCombinators/Poly/Parser.o dist/build/Text/ParserCombinators/Poly/Plain.o dist/build/Text/ParserCombinators/Poly/Lazy.o dist/build/Text/ParserCombinators/Poly/StateParser.o dist/build/Text/ParserCombinators/Poly/State.o dist/build/Text/ParserCombinators/Poly/StateLazy.o dist/build/Text/ParserCombinators/Poly/Lex.o dist/build/Text/Parse.o dist/build/Text/ParserCombinators/Poly/ByteString.o dist/build/Text/ParserCombinators/Poly/ByteStringChar.o dist/build/Text/Parse/ByteString.o dist/build/Text/ParserCombinators/Poly/Text.o dist/build/Text/ParserCombinators/Poly/StateText.o /usr/bin/ar: creating dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a /usr/bin/strip dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a --strip-unneeded /usr/bin/ghc -shared -dynamic -package-name polyparse-1.9 -no-auto-link- packages -package-db dist/package.conf.inplace -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id text-1.1.1.1-dd6849c4a01e66d368eb3b161ca67182 dist/build/Text/ParserCombinators/HuttonMeijer.dyn_o dist/build/Text/ParserCombinators/HuttonMeijerWallace.dyn_o dist/build/Text/ParserCombinators/Poly.dyn_o dist/build/Text/ParserCombinators/Poly/Base.dyn_o dist/build/Text/ParserCombinators/Poly/Result.dyn_o dist/build/Text/ParserCombinators/Poly/Parser.dyn_o dist/build/Text/ParserCombinators/Poly/Plain.dyn_o dist/build/Text/ParserCombinators/Poly/Lazy.dyn_o dist/build/Text/ParserCombinators/Poly/StateParser.dyn_o dist/build/Text/ParserCombinators/Poly/State.dyn_o dist/build/Text/ParserCombinators/Poly/StateLazy.dyn_o dist/build/Text/ParserCombinators/Poly/Lex.dyn_o dist/build/Text/Parse.dyn_o dist/build/Text/ParserCombinators/Poly/ByteString.dyn_o dist/build/Text/ParserCombinators/Poly/ByteStringChar.dyn_o dist/build/Text/Parse/ByteString.dyn_o dist/build/Text/ParserCombinators/Poly/Text.dyn_o dist/build/Text/ParserCombinators/Poly/StateText.dyn_o -o dist/build/libHSpolyparse-1.9-ghc7.8.2.so /usr/bin/ld: cannot find -lHStext-1.1.1.1-ghc7.8.2 collect2: error: ld returned 1 exit status Failed to install polyparse-1.9 Updating world file... cabal: Error: some packages failed to install: polyparse-1.9 failed during the building phase. The exception was: ExitFailure 1 }}} It happens with other packages as well. {{{hashable}}}, for example. The {{{text}}} that {{{polyparse}}} fails on is installed as a transitive dependency of {{{cabal-install}}}: {{{ ... [43 of 43] Compiling Data.Text.Read ( Data/Text/Read.hs, dist/build/Data/Text/Read.o ) Building C Sources... creating dist/build /usr/bin/ghc -c -odir dist/build -Idist/build -Iinclude -optc-O2 -package- db dist/package.conf.inplace -package-id array-0.5.0.0-9f212a0e8caa74d931af75060b4de2ab -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id deepseq-1.3.0.2-7160f83fdfe69b3794a2d7a3ad8d4c19 -package-id ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 -package-id integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 cbits/cbits.c Linking... /usr/bin/ar -r dist/build/libHStext-1.1.1.1.a dist/build/Data/Text.o dist/build/Data/Text/Array.o dist/build/Data/Text/Encoding.o dist/build/Data/Text/Encoding/Error.o dist/build/Data/Text/Foreign.o dist/build/Data/Text/IO.o dist/build/Data/Text/Internal.o dist/build/Data/Text/Internal/Builder.o dist/build/Data/Text/Internal/Builder/Functions.o dist/build/Data/Text/Internal/Builder/Int/Digits.o dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o dist/build/Data/Text/Internal/Encoding/Fusion.o dist/build/Data/Text/Internal/Encoding/Fusion/Common.o dist/build/Data/Text/Internal/Encoding/Utf16.o dist/build/Data/Text/Internal/Encoding/Utf32.o dist/build/Data/Text/Internal/Encoding/Utf8.o dist/build/Data/Text/Internal/Functions.o dist/build/Data/Text/Internal/Fusion.o dist/build/Data/Text/Internal/Fusion/CaseMapping.o dist/build/Data/Text/Internal/Fusion/Common.o dist/build/Data/Text/Internal/Fusion/Size.o dist/build/Data/Text/Internal/Fusion/Types.o dist/build/Data/Text/Internal/IO.o dist/build/Data/Text/Internal/Lazy.o dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o dist/build/Data/Text/Internal/Lazy/Fusion.o dist/build/Data/Text/Internal/Lazy/Search.o dist/build/Data/Text/Internal/Private.o dist/build/Data/Text/Internal/Read.o dist/build/Data/Text/Internal/Search.o dist/build/Data/Text/Internal/Unsafe.o dist/build/Data/Text/Internal/Unsafe/Char.o dist/build/Data/Text/Internal/Unsafe/Shift.o dist/build/Data/Text/Lazy.o dist/build/Data/Text/Lazy/Builder.o dist/build/Data/Text/Lazy/Builder/Int.o dist/build/Data/Text/Lazy/Builder/RealFloat.o dist/build/Data/Text/Lazy/Encoding.o dist/build/Data/Text/Lazy/IO.o dist/build/Data/Text/Lazy/Internal.o dist/build/Data/Text/Lazy/Read.o dist/build/Data/Text/Read.o dist/build/Data/Text/Unsafe.o dist/build/cbits/cbits.o /usr/bin/ar: creating dist/build/libHStext-1.1.1.1.a /usr/bin/ld -x -r -o dist/build/HStext-1.1.1.1.o dist/build/Data/Text.o dist/build/Data/Text/Array.o dist/build/Data/Text/Encoding.o dist/build/Data/Text/Encoding/Error.o dist/build/Data/Text/Foreign.o dist/build/Data/Text/IO.o dist/build/Data/Text/Internal.o dist/build/Data/Text/Internal/Builder.o dist/build/Data/Text/Internal/Builder/Functions.o dist/build/Data/Text/Internal/Builder/Int/Digits.o dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o dist/build/Data/Text/Internal/Encoding/Fusion.o dist/build/Data/Text/Internal/Encoding/Fusion/Common.o dist/build/Data/Text/Internal/Encoding/Utf16.o dist/build/Data/Text/Internal/Encoding/Utf32.o dist/build/Data/Text/Internal/Encoding/Utf8.o dist/build/Data/Text/Internal/Functions.o dist/build/Data/Text/Internal/Fusion.o dist/build/Data/Text/Internal/Fusion/CaseMapping.o dist/build/Data/Text/Internal/Fusion/Common.o dist/build/Data/Text/Internal/Fusion/Size.o dist/build/Data/Text/Internal/Fusion/Types.o dist/build/Data/Text/Internal/IO.o dist/build/Data/Text/Internal/Lazy.o dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o dist/build/Data/Text/Internal/Lazy/Fusion.o dist/build/Data/Text/Internal/Lazy/Search.o dist/build/Data/Text/Internal/Private.o dist/build/Data/Text/Internal/Read.o dist/build/Data/Text/Internal/Search.o dist/build/Data/Text/Internal/Unsafe.o dist/build/Data/Text/Internal/Unsafe/Char.o dist/build/Data/Text/Internal/Unsafe/Shift.o dist/build/Data/Text/Lazy.o dist/build/Data/Text/Lazy/Builder.o dist/build/Data/Text/Lazy/Builder/Int.o dist/build/Data/Text/Lazy/Builder/RealFloat.o dist/build/Data/Text/Lazy/Encoding.o dist/build/Data/Text/Lazy/IO.o dist/build/Data/Text/Lazy/Internal.o dist/build/Data/Text/Lazy/Read.o dist/build/Data/Text/Read.o dist/build/Data/Text/Unsafe.o dist/build/cbits/cbits.o In-place registering text-1.1.1.1... /usr/bin/ghc-pkg update - --global --user --package- db=dist/package.conf.inplace directory dist/doc/html/text does exist: False creating /home/intrados/.cabal/share/doc/text-1.1.1.1 Installing LICENSE to /home/intrados/.cabal/share/doc/text-1.1.1.1/LICENSE Installing library in /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2 creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2 creating /home/intrados/.cabal/lib/text-1.1.1.1 creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2 creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Int creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/RealFloat creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder Installing dist/build/Data/Text.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text.hi Installing dist/build/Data/Text/Array.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Array.hi Installing dist/build/Data/Text/Encoding.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding.hi Installing dist/build/Data/Text/Encoding/Error.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding/Error.hi Installing dist/build/Data/Text/Foreign.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Foreign.hi Installing dist/build/Data/Text/IO.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/IO.hi Installing dist/build/Data/Text/Internal.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal.hi Installing dist/build/Data/Text/Internal/Builder.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder.hi Installing dist/build/Data/Text/Internal/Builder/Functions.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Functions.hi Installing dist/build/Data/Text/Internal/Builder/Int/Digits.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Int/Digits.hi Installing dist/build/Data/Text/Internal/Builder/RealFloat/Functions.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/RealFloat/Functions.hi Installing dist/build/Data/Text/Internal/Encoding/Fusion.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion.hi Installing dist/build/Data/Text/Internal/Encoding/Fusion/Common.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion/Common.hi Installing dist/build/Data/Text/Internal/Encoding/Utf16.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf16.hi Installing dist/build/Data/Text/Internal/Encoding/Utf32.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf32.hi Installing dist/build/Data/Text/Internal/Encoding/Utf8.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf8.hi Installing dist/build/Data/Text/Internal/Functions.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Functions.hi Installing dist/build/Data/Text/Internal/Fusion.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion.hi Installing dist/build/Data/Text/Internal/Fusion/CaseMapping.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/CaseMapping.hi Installing dist/build/Data/Text/Internal/Fusion/Common.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Common.hi Installing dist/build/Data/Text/Internal/Fusion/Size.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Size.hi Installing dist/build/Data/Text/Internal/Fusion/Types.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Types.hi Installing dist/build/Data/Text/Internal/IO.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/IO.hi Installing dist/build/Data/Text/Internal/Lazy.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy.hi Installing dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding/Fusion.hi Installing dist/build/Data/Text/Internal/Lazy/Fusion.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Fusion.hi Installing dist/build/Data/Text/Internal/Lazy/Search.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Search.hi Installing dist/build/Data/Text/Internal/Private.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Private.hi Installing dist/build/Data/Text/Internal/Read.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Read.hi Installing dist/build/Data/Text/Internal/Search.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Search.hi Installing dist/build/Data/Text/Internal/Unsafe.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe.hi Installing dist/build/Data/Text/Internal/Unsafe/Char.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe/Char.hi Installing dist/build/Data/Text/Internal/Unsafe/Shift.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe/Shift.hi Installing dist/build/Data/Text/Lazy.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy.hi Installing dist/build/Data/Text/Lazy/Builder.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder.hi Installing dist/build/Data/Text/Lazy/Builder/Int.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder/Int.hi Installing dist/build/Data/Text/Lazy/Builder/RealFloat.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder/RealFloat.hi Installing dist/build/Data/Text/Lazy/Encoding.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Encoding.hi Installing dist/build/Data/Text/Lazy/IO.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/IO.hi Installing dist/build/Data/Text/Lazy/Internal.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Internal.hi Installing dist/build/Data/Text/Lazy/Read.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Read.hi Installing dist/build/Data/Text/Read.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Read.hi Installing dist/build/Data/Text/Unsafe.hi to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Unsafe.hi creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2 Installing dist/build/libHStext-1.1.1.1.a to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/libHStext-1.1.1.1.a creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2 Installing dist/build/HStext-1.1.1.1.o to /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/HStext-1.1.1.1.o /usr/bin/ghc --abi-hash -fbuilding-cabal-package -O -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP- DINTEGER_GMP -optP-DHAVE_DEEPSEQ -optP-include -optPdist/build/autogen/cabal_macros.h -package-name text-1.1.1.1 -hide- all-packages -package-id array-0.5.0.0-9f212a0e8caa74d931af75060b4de2ab -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id deepseq-1.3.0.2-7160f83fdfe69b3794a2d7a3ad8d4c19 -package-id ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 -package-id integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 -XHaskell98 Data.Text Data.Text.Array Data.Text.Encoding Data.Text.Encoding.Error Data.Text.Foreign Data.Text.IO Data.Text.Internal Data.Text.Internal.Builder Data.Text.Internal.Builder.Functions Data.Text.Internal.Builder.Int.Digits Data.Text.Internal.Builder.RealFloat.Functions Data.Text.Internal.Encoding.Fusion Data.Text.Internal.Encoding.Fusion.Common Data.Text.Internal.Encoding.Utf16 Data.Text.Internal.Encoding.Utf32 Data.Text.Internal.Encoding.Utf8 Data.Text.Internal.Functions Data.Text.Internal.Fusion Data.Text.Internal.Fusion.CaseMapping Data.Text.Internal.Fusion.Common Data.Text.Internal.Fusion.Size Data.Text.Internal.Fusion.Types Data.Text.Internal.IO Data.Text.Internal.Lazy Data.Text.Internal.Lazy.Encoding.Fusion Data.Text.Internal.Lazy.Fusion Data.Text.Internal.Lazy.Search Data.Text.Internal.Private Data.Text.Internal.Read Data.Text.Internal.Search Data.Text.Internal.Unsafe Data.Text.Internal.Unsafe.Char Data.Text.Internal.Unsafe.Shift Data.Text.Lazy Data.Text.Lazy.Builder Data.Text.Lazy.Builder.Int Data.Text.Lazy.Builder.RealFloat Data.Text.Lazy.Encoding Data.Text.Lazy.IO Data.Text.Lazy.Internal Data.Text.Lazy.Read Data.Text.Read Data.Text.Unsafe -Wall -fwarn-tabs -funbox-strict-fields -O2 Registering text-1.1.1.1... /usr/bin/ghc-pkg update - --global --user Installed text-1.1.1.1 }}} The same procedure succeeds with a clean GHC 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 19:27:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 19:27:37 -0000 Subject: [GHC] #9060: `cabal` linking error with GHC 7.8.2 In-Reply-To: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> References: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> Message-ID: <063.67f6b10db65325a9edb5bfcd9dfb77c8@haskell.org> #9060: `cabal` linking error with GHC 7.8.2 -----------------------------------+---------------------------------- Reporter: pseudonom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by pseudonom): It looks as thought cabal is expecting {{{HStext-1.1.1.1-ghc7.8.2}}} but only {{{HStext-1.1.1.1}}} is provided. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 19:37:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 19:37:43 -0000 Subject: [GHC] #9060: `cabal` linking error with GHC 7.8.2 In-Reply-To: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> References: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> Message-ID: <063.1e49f9e84f7022e160f516ba8b063c45@haskell.org> #9060: `cabal` linking error with GHC 7.8.2 -----------------------------------+---------------------------------- Reporter: pseudonom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by tibbe): I think this might be related to dynamic linking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 19:38:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 19:38:30 -0000 Subject: [GHC] #9060: `cabal` linking error with GHC 7.8.2 In-Reply-To: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> References: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> Message-ID: <063.4bb28172285d0e2f15947278b0981984@haskell.org> #9060: `cabal` linking error with GHC 7.8.2 -----------------------------------+---------------------------------- Reporter: pseudonom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 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): You seem to be trying to build a dynamic `polyparse` library but you only have a static `text` library, probably because the default of what kind of libraries to build changed between cabal 1.16 and cabal 1.20. Try reinstalling the text library (or just blowing away your whole 7.8.2 packages tree). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 19:44:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 19:44:43 -0000 Subject: [GHC] #9060: `cabal` linking error with GHC 7.8.2 In-Reply-To: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> References: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> Message-ID: <063.f08d5ab7dde9c4df7550924a4724de69@haskell.org> #9060: `cabal` linking error with GHC 7.8.2 -----------------------------------+---------------------------------- Reporter: pseudonom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by tibbe): @rwbarton, I think pseudonom did blow away the whole tree. text is pulled in by cabal-install (through network > parsec > text) so it ought to have been built in a dynamic way if polyparse was. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 20:03:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 20:03:59 -0000 Subject: [GHC] #9060: `cabal` linking error with GHC 7.8.2 In-Reply-To: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> References: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> Message-ID: <063.accfd891923060291f78832bafe29a61@haskell.org> #9060: `cabal` linking error with GHC 7.8.2 -----------------------------------+---------------------------------- Reporter: pseudonom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 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): tibbe: there are two steps involved here with different versions of cabal. First cabal 1.16 installed cabal 1.20, and as a side effect, installed text too. Since cabal 1.16 did the building, it installed a static library for text. Then cabal 1.20 tried to build a dynamic library for polyparse so it looked for a dynamic library for text. Keep the cabal 1.20 binary and blow away `~/.ghc` and then cabal 1.20 should be able to install (a dynamic library for) polyparse without any problems. Or, start the whole process with cabal 1.18 or newer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 20:10:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 20:10:30 -0000 Subject: [GHC] #9060: `cabal` linking error with GHC 7.8.2 In-Reply-To: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> References: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> Message-ID: <063.d93c9094a04bde818066c176d08c638e@haskell.org> #9060: `cabal` linking error with GHC 7.8.2 -----------------------------------+---------------------------------- Reporter: pseudonom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by pseudonom): Ah, that makes sense. Thanks. It all works after getting rid of ~/.ghc and retrying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 20:13:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 20:13:00 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.68b2dfc2159cfecfe9c94cc59f0c83cb@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 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 ocharles): I believe I am running into this bug: {{{ ollie at nixos ~/w/ghc> nix-shell --pure -I /home/ollie -p haskellPackages_ghc782.ghc haskellPackages.cabalInstall -p haskellPackages_ghc782.happy haskellPackages_ghc782.alex -p ncurses -p gnum4 [nix-shell:~/work/ghc/libraries/base]$ make make -C ../.. all_libraries/base make[1]: Entering directory `/home/ollie/work/ghc' ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[2]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[2]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all_libraries/base "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/include -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 -optl-L'/home/ollie/work/ghc/libraries/ghc-prim/dist-install/build' -optl-L'/home/ollie/work/ghc/rts/dist/build' -optl-lm -optl-lrt -optl-ldl -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/include -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 -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.9.20140430.so Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. /nix/store/xjvdpqgn2kd4rg0k30z020kxylvlbpx0-binutils-2.23.1/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_add' 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: error: ld returned 1 exit status make[2]: *** [libraries/integer-gmp/dist-install/build/libHSinteger- gmp-0.5.1.0-ghc7.9.20140430.so] Error 1 make[1]: *** [all_libraries/base] Error 2 make[1]: Leaving directory `/home/ollie/work/ghc' make: *** [all] Error 2 }}} If anyone has anything they'd like me to try - suggest away! I'm at revision 34db5ccf52ec2a1b5e953c282d0c52a7fc82c02a (at least in the root of the source tree), and my nixpkgs is e001ac6a9ee3e3f1d755c16d1a27e5ce75a76902 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 21:46:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 21:46:22 -0000 Subject: [GHC] #9060: `cabal` linking error with GHC 7.8.2 In-Reply-To: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> References: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> Message-ID: <063.14582d6cb8e7cad389b21a1e6fbb01b7@haskell.org> #9060: `cabal` linking error with GHC 7.8.2 -----------------------------------+---------------------------------- Reporter: pseudonom | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by tibbe): * status: new => closed * resolution: => invalid Comment: rwbarton: Thanks for explanation. I think we ought to warn users somehow, probably by having cabal check for the presence of the dynamic library and erroring out earlier with a better error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 30 22:45:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Apr 2014 22:45:34 -0000 Subject: [GHC] #9060: `cabal` linking error with GHC 7.8.2 In-Reply-To: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> References: <048.df5410eff3f1e337995ce7968d6cda34@haskell.org> Message-ID: <063.dde3f2b3a656073e0f7b67b5dc4b5f81@haskell.org> #9060: `cabal` linking error with GHC 7.8.2 -----------------------------------+---------------------------------- Reporter: pseudonom | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by rwbarton): Yes, agreed. My initial reaction is (as you say) that cabal is the proper place for this check. -- Ticket URL: GHC The Glasgow Haskell Compiler