December 2015 - ghc-devs

ghc-split??
by Simon Peyton Jones 18 Dec '15

18 Dec '15

I’m getting this with a clean HEAD on Linux. Any ideas? Simon ghc-stage1: could not execute: /5playpen/simonpj/HEAD-4/inplace/lib/bin/ghc-split make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1

3 4

Re: Performance of pattern checker on OptCoercions
by Richard Eisenberg 17 Dec '15

17 Dec '15

On Dec 17, 2015, at 1:31 PM, George Karachalias <george.karachalias(a)gmail.com> wrote: > > My single last concern is what I wrote earlier: "Flags 2 and 3 are a bit tricky: Actual bailing > will uglify the code and make it much more complicated so I would prefer in practice to just > check up front with a good metric whether the possibility to be non-performant is high and in > these cases just not call the checker at all." > > If we agree on this one, I am gonna wrap it up in the next 2 days. :-) I'm quite happy with this. My thought is that if it's a bit wrong, that's OK -- we'll refine the settings over time. Others? Richard

1 0

Re: Performance of pattern checker on OptCoercions
by Richard Eisenberg 17 Dec '15

17 Dec '15

On Dec 17, 2015, at 8:15 AM, George Karachalias <george.karachalias(a)gmail.com> wrote: > What do you think? I have already implemented a first patch with two options: If the number of > guards is small run the check and say nothing. If not, check for 2 possible flags: > -fwarn-pattern-guards ==> Give it your best > -fwarn-ignore-pattern-guards ==> Do not run the check on the cases with many guards without a warning > None of the two enabled? ==> Give a warning of the form: > > T783.hs:4:1: warning: > Pattern match checking failed for an equation for foo > due to the big number of guards > (Use -fwarn-ignore-pattern-guards if you want to hide this message > or -fwarn-pattern-guards if you want the checker to run no matter what) I don't have much comment on your implementation techniques, as I don't know this end of the operation well enough to have an opinion. For the point above: what if both flags are enabled? Richard

1 0

question about coercions between primitive types in STG level
by Ömer Sinan Ağacan 17 Dec '15

17 Dec '15

Hi all, In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some unsafe coercions at the STG level. It works fine for lifted types, but for unlifted ones I'm having some problems. What I'm trying to do is given a number of primitive types I'm finding the one with biggest size, and then generating a constructor that takes this biggest primitive type as argument. The problem is that this is not working very well - GHC is generating illegal instructions that try to load a F32 value to a register allocated for I64, using movss instruction. CoreLint is catching this error and printing this: Cmm lint error: in basic block c1hF in assignment: _g16W::I64 = 4.5 :: W32; // CmmAssign Reg ty: I64 Rhs ty: F32 So I have two questions about this: 1. Is there a way to safely do this? What are my options here? What I'm trying to do is to use a single data constructor field for different primitive types. The field is guaranteed to be as big as necessary. 2. In the Cmm code shown above, the type annotation is showing `W32` but in the error message it says `F32`. I'm confused about this, is this error message given because the sizes don't match? (64bits vs 32bits) Why the type annotation says W32 while the value has type F32? Thanks..

5 8

GHC 8.0 feature freeze imminent
by Ben Gamari 17 Dec '15

17 Dec '15

Hello GHCers, Last Friday Richard Eisenberg's long-awaited no-kinds branch landed in `master`. Being one of the defining features of the 8.0 release, we bent the feature freeze schedule (initially slated for sometime last week) a bit to accomodate this piece of work. Now that Richard's work is in, we will set the official freeze date for Monday December 21st so that there is time to review and merge some queued work which we've been queuing for after the no-kinds merge. If you have work still outstanding then you should talk to either me or Austin ASAP if you have not done so already. We will be discussing the release schedule for 8.0 during the GHC today. Cheers, - Ben

4 5

Harbormaster acting up?
by Richard Eisenberg 17 Dec '15

17 Dec '15

Hi devs, Is Harbormaster acting up? I saw today two out-of-memory failures, including this one (https://phabricator.haskell.org/harbormaster/build/9150/) which happens when building the stage-1 compiler. That means that an off-the-shelf GHC is the one that's running out of memory. Separately, a comments-only patch didn't validate (https://phabricator.haskell.org/harbormaster/build/9148/) Any hints? Thanks! Richard

2 1

Unused type variables with non-linear patterns
by Jan Stolarek 15 Dec '15

15 Dec '15

An intersting thing came up when implementing warnings for unused type variables in type family patterns (#10982 / D1576): type family X a b where X a a = Int Should we emit a warning that `a` is unused? It does not appear in the RHS but it is actually used because of non-linear pattern. We can fix this by prefixing both appearances of `a` with an underscore - this silences the warning and maintains semantics. Nevertheless, if a variable is unused it should be perfectly valid to replace it with an underscore - that is not the case in this example. Thoughts? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

4 4

Warning suppression pragmas
by Эдгар Жаворонков 15 Dec '15

15 Dec '15

Hello devs! I am trying to implement some kind of local warnings suppresion and i need some help. I want to use a pragma to mark functions so compiler won't throw warnings from them. I defined my pragma in lexer, parser and added type signature in HsBinds.hs. And i am stuck. I don't know what to do. What should i consider doing further? I designed a small wiki page here - https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas So if you have nice examples, feel free to add them. Thanks for your help in advance! --- С уважением, Жаворонков Эдгар Best regards, Edgar A. Zhavoronkov

4 4

-XStrict: Why some binders are not made strict?
by Ömer Sinan Ağacan 15 Dec '15

15 Dec '15

Let's say I have this code: zip :: [a] -> [b] -> [(a, b)] zip [] [] = [] zip (x : xs) (y : ys) = (x, y) : zip xs ys With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering about the motivation behind this, I found this interesting. I always thought -XStrict gives me this guarantee: If I'm using an already-defined variable(bound by a let or pattern matching) in an expression, I can be sure that the variable won't be bottom in that expression, because it would be `seq`d before the expression is evaluated. So if I have case ... of D x y -> <body> or let x = ... y = ... in <body> In both cases I was thinking that in <body> 'x' and 'y' can't be bottom(with -XStrict). This would make -XStrict programs evaluate like they would in a call-by-value language(even though in the RTS level thunks will be built). Variables can't range over computations; all binders evaluated strictly etc. Can anyone tell me about the motivation behind this decision? I think the wiki page actually conflicts with itself. It says "... bindings to be strict by default" but then in "case expressions" sections says case x of (a,b) -> rhs is interpreted as case x of !(a,b) -> rhs Here bindings 'a' and 'b' are not made strict. I'd expect something like: case x of (!a,!b) -> rhs (Which seems to be invalid Haskell, but same effect could be achieved with `seq a (seq b rhs)`) Thanks.. (I also realized that the wiki page doesn't mention bindings in do syntax, is it because this case is implied by "function definitions"? That is, bangs are added after do syntax is desugared and so they become strict?)

6 16

RE: [commit: ghc] master: Make sure PatSyns only get added once to tcg_patsyns (41ef8f7)
by Simon Peyton Jones 15 Dec '15

15 Dec '15

Good catch Matthew! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 11 December 2015 18:12 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Make sure PatSyns only get added once | to tcg_patsyns (41ef8f7) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.ha | skell.org%2ftrac%2fghc%2fchangeset%2f41ef8f70819e9b99aacc6d81019e5a33a | 63dfeab%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd98265 | a98dcc44ba27f808d30256abde%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat | a=aH%2bCJDOGW%2f2iqa%2fVNndOfAq2bJfBRBGiCADHYBzt5Uc%3d | | >--------------------------------------------------------------- | | commit 41ef8f70819e9b99aacc6d81019e5a33a63dfeab | Author: Matthew Pickering <matthewtpickering(a)gmail.com> | Date: Fri Dec 11 18:10:45 2015 +0000 | | Make sure PatSyns only get added once to tcg_patsyns | | Summary: Before, `PatSyn`s were getting added twice to | `tcg_patsyns` so | when inspecting afterwards there were duplicates in the list. | This makes sure that only they only get added once. | | Reviewers: austin, bgamari | | Reviewed By: bgamari | | Subscribers: thomie | | Differential Revision: https://phabricator.haskell.org/D1597 | | | >--------------------------------------------------------------- | | 41ef8f70819e9b99aacc6d81019e5a33a63dfeab | compiler/typecheck/TcBinds.hs | 8 +++----- | compiler/typecheck/TcPatSyn.hs | 10 +++++----- | compiler/typecheck/TcPatSyn.hs-boot | 7 +++---- | 3 files changed, 11 insertions(+), 14 deletions(-) | | diff --git a/compiler/typecheck/TcBinds.hs | b/compiler/typecheck/TcBinds.hs index 673109b..1254b78 100644 | --- a/compiler/typecheck/TcBinds.hs | +++ b/compiler/typecheck/TcBinds.hs | @@ -49,7 +49,6 @@ import NameSet | import NameEnv | import SrcLoc | import Bag | -import PatSyn | import ListSetOps | import ErrUtils | import Digraph | @@ -483,13 +482,12 @@ tc_single :: forall thing. | -> LHsBind Name -> TcM thing | -> TcM (LHsBinds TcId, thing) tc_single _top_lvl sig_fn | _prag_fn (L _ (PatSynBind psb@PSB{ psb_id = L _ name })) thing_inside | - = do { (pat_syn, aux_binds, tcg_env) <- tc_pat_syn_decl | - ; let tything = AConLike (PatSynCon pat_syn) | - ; thing <- setGblEnv tcg_env $ tcExtendGlobalEnv [tything] | thing_inside | + = do { (aux_binds, tcg_env) <- tc_pat_syn_decl | + ; thing <- setGblEnv tcg_env thing_inside | ; return (aux_binds, thing) | } | where | - tc_pat_syn_decl :: TcM (PatSyn, LHsBinds TcId, TcGblEnv) | + tc_pat_syn_decl :: TcM (LHsBinds TcId, TcGblEnv) | tc_pat_syn_decl = case sig_fn name of | Nothing -> tcInferPatSynDecl psb | Just (TcPatSynSig tpsi) -> tcCheckPatSynDecl psb tpsi diff -- | git a/compiler/typecheck/TcPatSyn.hs b/compiler/typecheck/TcPatSyn.hs | index 30dcbf7..69eeef0 100644 | --- a/compiler/typecheck/TcPatSyn.hs | +++ b/compiler/typecheck/TcPatSyn.hs | @@ -61,7 +61,7 @@ import Control.Monad (forM) -} | | tcInferPatSynDecl :: PatSynBind Name Name | - -> TcM (PatSyn, LHsBinds Id, TcGblEnv) | + -> TcM (LHsBinds Id, TcGblEnv) | tcInferPatSynDecl PSB{ psb_id = lname@(L loc name), psb_args = | details, | psb_def = lpat, psb_dir = dir } | = setSrcSpan loc $ | @@ -96,7 +96,7 @@ tcInferPatSynDecl PSB{ psb_id = lname@(L loc name), | psb_args = details, | | tcCheckPatSynDecl :: PatSynBind Name Name | -> TcPatSynInfo | - -> TcM (PatSyn, LHsBinds Id, TcGblEnv) | + -> TcM (LHsBinds Id, TcGblEnv) | tcCheckPatSynDecl PSB{ psb_id = lname@(L loc name), psb_args = | details, | psb_def = lpat, psb_dir = dir } | TPSI{ patsig_tau = tau, @@ -163,7 +163,7 @@ | tcCheckPatSynDecl PSB{ psb_id = lname@(L loc name), psb_args = | details, | (univ_tvs, req_theta, req_ev_binds, | req_dicts) | (ex_tvs, ex_tys, prov_theta, prov_ev_binds, | prov_dicts) | wrapped_args | - pat_ty rec_fields } | + pat_ty rec_fields } | where | (arg_tys, pat_ty) = tcSplitFunTys tau | | @@ -199,7 +199,7 @@ tc_patsyn_finish :: Located Name -- ^ PatSyn Name | -> TcType -- ^ Pattern type | -> [Name] -- ^ Selector names | -- ^ Whether fields, empty if not record PatSyn | - -> TcM (PatSyn, LHsBinds Id, TcGblEnv) | + -> TcM (LHsBinds Id, TcGblEnv) | tc_patsyn_finish lname dir is_infix lpat' | (univ_tvs, req_theta, req_ev_binds, req_dicts) | (ex_tvs, subst, prov_theta, prov_ev_binds, | prov_dicts) @@ -262,7 +262,7 @@ tc_patsyn_finish lname dir is_infix | lpat' | tcRecSelBinds | (ValBindsOut (zip (repeat NonRecursive) selector_binds) | sigs) | | - ; return (patSyn, matcher_bind, tcg_env) } | + ; return (matcher_bind, tcg_env) } | | where | zonk_wrapped_arg :: (Var, HsWrapper) -> TcM (Var, HsWrapper) diff | --git a/compiler/typecheck/TcPatSyn.hs-boot | b/compiler/typecheck/TcPatSyn.hs-boot | index 61f7958..11c1bc1 100644 | --- a/compiler/typecheck/TcPatSyn.hs-boot | +++ b/compiler/typecheck/TcPatSyn.hs-boot | @@ -4,16 +4,15 @@ import Name ( Name ) | import Id ( Id ) | import HsSyn ( PatSynBind, LHsBinds ) | import TcRnTypes ( TcM, TcPatSynInfo ) | -import PatSyn ( PatSyn ) | -import TcRnMonad ( TcGblEnv ) | +import TcRnMonad ( TcGblEnv) | import Outputable ( Outputable ) | | tcInferPatSynDecl :: PatSynBind Name Name | - -> TcM (PatSyn, LHsBinds Id, TcGblEnv) | + -> TcM (LHsBinds Id, TcGblEnv) | | tcCheckPatSynDecl :: PatSynBind Name Name | -> TcPatSynInfo | - -> TcM (PatSyn, LHsBinds Id, TcGblEnv) | + -> TcM (LHsBinds Id, TcGblEnv) | | tcPatSynBuilderBind :: PatSynBind Name Name | -> TcM (LHsBinds Id) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd98265a98dcc | 44ba27f808d30256abde%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B6Hb | JaANWHnlqhBaZ5AOMvHAQ0Mzs4t8cvtkQLIo4t4%3d

1 0