February 2014 - ghc-tickets

[GHC] #8301: error BaseReg must be in a register for THREADED_RTS
by GHC 18 Feb '14

18 Feb '14

#8301: error BaseReg must be in a register for THREADED_RTS -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------------- Compiling git HEAD on powerpc64-linux. This was working as recently as two weeks ago. Now getting: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name ghc-7.7.20130914 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage2 -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.3.1 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package time-1.4.1 -package transformers-0.3.0.0 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -DNO_REGS -optc-DTHREADED_RTS -DSTAGE=2 -O2 -fwarn-tabs -fno-warn-amp -O -dcore-lint -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -c compiler/utils/Platform.hs -o compiler/stage2/build/Platform.o In file included from /home/erikd/PPC64/ghc-ppc64/includes/Stg.h:232:0: 0, from /tmp/ghc10950_0/ghc10950_2.hc:3: /home/erikd/PPC64/ghc-ppc64/includes/stg/Regs.h:359:2: error: #error BaseReg must be in a register for THREADED_RTS }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

Re: [GHC] #3034: divInt# floated into a position which leads to low arity
by GHC 18 Feb '14

18 Feb '14

#3034: divInt# floated into a position which leads to low arity --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): For an example where we don't want to duplicate primops, see #5623 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3034#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3034: divInt# floated into a position which leads to low arity
by GHC 17 Feb '14

17 Feb '14

#3034: divInt# floated into a position which leads to low arity --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => patch Comment: Changing `primOpIsCheap` to always True validates, and has no allocation change in nofib. I guess I should be measuring runtime numbers, but for that I’ll need the machine to be unloaded, maybe later today.... Alright, numbers are in: {{{ Min -0.0% -0.0% -7.1% -6.5% -1.8% Max +0.0% +0.0% +2.1% +1.5% +19.8% Geometric Mean -0.0% -0.0% -0.6% -0.5% +0.2% }}} so it seems to be worth it. Not pushing quite yet: Assuming we make the cheapness configurable in `primops.txt.pp`, what primops should not be cheap? To me all of them look cheap (e.g. arithmetic) or are side-effecting (like `copyArray#`, in which case the `primOpIsCheap` information hopefully has no effect. So it seems to me that we do not need to a flag in `primops.txt.pp` just yet; maybe something will show up later. (Marking as for review without a patch because the patch is trivial; it is this question that need to be reviewed.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3034#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2915: Arity is smaller than need be
by GHC 17 Feb '14

17 Feb '14

#2915: Arity is smaller than need be --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner <mail@…>): In [changeset:"2931d19e90d2366f2ce308d65a36333336ca6059/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2931d19e90d2366f2ce308d65a36333336ca6059" More liberally eta-expand a case-expression at least with -fno-pedantic-bottoms. This fixes #2915, and undoes some of a522c3b, on the grounds that with a flag `-fpedantic-bottoms` around, we can be a bit more liberal when the flag is off.. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2915#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2915: Arity is smaller than need be
by GHC 17 Feb '14

17 Feb '14

#2915: Arity is smaller than need be --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: infoneeded => closed * resolution: => fixed Comment: It seems that not test cases fail with this change, and only one nofib benchmark profits (mandel -1.9%). It would also simplify `CoreArity` (no need for the `ae_bndrs` field). (Or course the scrunitee must not be expensive; I guard this using the `ae_cheap_fn`. If I don't do that, fluid improves allocation by -2.3%, but of course it's wrong. In most cases, though, FloatOut will have ensured that the scrutinee is cheap) I’ll need to run another round of nofib, with an unloaded machine, to ensure that the runtimes are still ok... and here it is {{{ Min -0.1% -1.9% -3.0% -2.9% 0.0% Max +0.0% +0.0% +3.5% +2.2% +3.8% Geometric Mean -0.0% -0.0% -0.4% -0.4% +0.0% }}} Runtime varies a bit, with a slight tendency to an improvement. Guess that is good enough to push. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2915#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5974: Casts, rules, and parametricity
by GHC 17 Feb '14

17 Feb '14

#5974: Casts, rules, and parametricity -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): When matching a lambda `(\x -> g x)` against an expression `(\y -> f y) |> γ`, since [a27b2985] it will push the coercion γ inside the lambda, see `pushCoercionIntoLambda` in source:compiler/coreSyn/CoreSubst.lhs. Similar pushing around could help in other cases where RULES fail to match due to coercions. Also, the ability to mention `coerce` in a RULE (and have it match all kind of coercions) could help with the issues of this tickets. A rule `{-# RULES "foo" forall (f:: y -> z) (xs :: [x]) . map f (coerce xs) = map (coerce f) xs #-}` would possibly help here, but needs more power in the type checker, namely the deconstruction of `Coercible` constraints: {{{ T5974.hs:4:76: Could not coerce from ‛y’ to ‛x’ because ‛y’ and ‛x’ are different types. arising from a use of ‛coerce’ from the context (Coercible [x] [y]) bound by the RULE "foo" at T5974.hs:4:11-87 In the first argument of ‛map’, namely ‛(coerce f)’ In the expression: map (coerce f) xs When checking the transformation rule "foo" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5974#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8797: Buy fresh foods that require preparation like lean proteins, veggies, and fruits. Processed, ready to eat foods have very little nutritional value.
by GHC 17 Feb '14

17 Feb '14

#8797: Buy fresh foods that require preparation like lean proteins, veggies, and fruits. Processed, ready to eat foods have very little nutritional value. ------------------------------------+------------------------------------- Reporter: racquelrodriquez | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: GOJI ACTIVES | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If you requirement to turn exploit rid of tumesce fat andantino, you moldiness learn how to set up your daily nutrition and practice so you can course conscionable commence losing tumefy fat. You don't soul to achieve Vast changes in what you do, vindicatory advantage making any weensy changes that leave pay off big example in the later. GOJI ACTIVES You can't start feat rid of swell fat if you don't vantage dynamic what you're doing. Dwarfish changes in your day to day number will hit a big disagreement when it comes to feat rid of swell fat rapid. Same a snowball that gets large when it's trilled land the comic... making undersized changes in your daily fast and lesson function present spring you statesman force that can diffuse you towards your end of a mat viscus. It all starts with your regular nutrition. You are what you eat... so be solon alive of what you're swing into your embody. Interrupt uptake time you're watching TV and instead, grasp out with a someone or know a picnic. Start to bask the trait that's accomplishment on AROUND your matter... and don't put so more pleasure on the food itself. Careful, it's okay to focalise on the pleasures of the substance you eat, but don't cogitate content so untold land that you but can't decide when to occlusive feeding. Instead, use content as what it is: an strength germ for your embody and naught added. Signaling to relish the consort of friends and home or the scenic environment of a holiday. By not swing so more pleasure into the content itself, you can vantage reducing your daily kilocalorie intake which leave service with effort rid of tumesce fat. It's OK to going something on your containerful if you look slaked before you're dressed. You don't hit to act your content and crystallise your shell when you eat, especially when you want to lose whatever tummy fat. Commencement using seemly proportions when you variety your meals. Bed out a rhythmic abstraction of matter and put it on your scale. This way, you mate just how overmuch you're having. Don't go market shopping on an lifeless stomach. That's a instruction for purchase much foods you don't requirement, especially junk foods. Instead, go shopping after you virtuous ate and workplace from a preconditioned list. GOJI ACTIVES Now, the healthy interest is, you don't ever bonk to completely furnish up all your competition foods. You righteous feature to commence reaction them and having them in relief. Pay attending to the delivery filler, especially how umteen servings there are in the substance you're exploit to eat. You deprivation to commencement reducing your daily calorie intake so that getting rid of tumefy fat retributory happens. And the fastest way to do that is by slowly reaction your part sizes. The calorie concept of substance labels can work you win your metric (earn, worsen or hold.) The company of servings you deplete determines the limit of calories you actually eat. Also, be many alert of sugars, metal, and sopping fats... both of which are usually institute in cured foods. Intake too often pure fat, trans fat, cholesterin, or metal may amount your essay of confident diseases suchlike heart disease, soul, or shrill murder somaesthesia. Sugars allow fructose in fruit and disaccharide in dairy products as source as additional sugars much as saccharose (tableland dulcify). Nutritionally, dulcorate is a lyrate carbohydrates that's void calories. http://www.gojiactivesfuncionabr.com/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2915: Arity is smaller than need be
by GHC 17 Feb '14

17 Feb '14

#2915: Arity is smaller than need be --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: infoneeded Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Reading more code I found this change (a522c3b25eea1fe40edae7052335acce75e8a1c3) introduced in response to #5625, which prevents this eta-expansion to be pedantic about bottoms. The `-fpedantic-bottoms` check was added later. So I guess one could argue that if this flag is off, we should go back to the more liberal eta- expansion. I’ll try that and see what happens. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2915#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7596: Opportunity to improve CSE
by GHC 17 Feb '14

17 Feb '14

#7596: Opportunity to improve CSE -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I wrote a small wiki page with some of my findings, if you work on CSE you might find some of it useful: [[MoreCSE]]. Not many hard insights there, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7596#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5682: Properly parse promoted data constructor operators
by GHC 17 Feb '14

17 Feb '14

#5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 (Parser) | Keywords: PolyKinds, ghc- Resolution: fixed | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 parser/should_compile/T5682 | Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5682#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0