January 2016 - ghc-devs

cpphs: can't be used to build GHC 7.10.3. Bug?
by Alain O'Dea 10 Jan '16

10 Jan '16

Hi Malcolm: cpphs is under consideration as a replacement for GCC's C preprocessor in the GHC toolchain: https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp GHC 7.10.3's build fails when cpphs is used as the C preprocessor (--with-hs-cpp=cpphs --with-hs-cpp-flags="--cpp"). It runs into this error when preprocessing libraries/base/GHC/Natural.hs: cpphs: macro MIN_VERSION_integer_gmp expected 3 arguments, but was given 0 I've reproduced this issue on Ubuntu 14.04 x86-64 and SmartOS 15.3.0 x86-64. Interestingly the error seems to arise only when preprocessing Natural.hs while the autogenerated cabal-macros.h is present. Removing that include from the cpphs flags leads to a clean preprocessing run. I have more details of this investigation here: https://gist.github.com/AlainODea/bd5b3e0e6f7c4227f009 Is this a bug? Best, Alain

2 4

NOINLINE effects worker/wrapper - why and how to fix?
by Ömer Sinan Ağacan 09 Jan '16

09 Jan '16

So I was doing some micro benchmarks and I realized that adding NOINLINE to a function somehow prevents worker/wrapper. Imagine this factorial function which has a very obvious worker/wrapper opportunity: fac :: Int -> Int fac 0 = 1 fac n = n * fac (n - 1) If I add NOINLINE to this, no matter what -O I use, I get this STG: fac = \r srt:SRT:[] [ds_s38j] case ds_s38j of _ { I# ds1_s38l -> case ds1_s38l of ds2_s38m { __DEFAULT -> case -# [ds2_s38m 1#] of sat_s38n { __DEFAULT -> let { sat_s38o = NO_CCS I#! [sat_s38n]; } in case fac sat_s38o of _ { I# y_s38q -> case *# [ds2_s38m y_s38q] of sat_s38r { __DEFAULT -> I# [sat_s38r]; }; }; }; 0# -> lvl_r38f; }; }; Which doesn't have worker/wrapper. When I remove NOINLINE I get this worker/wrappered version as expected: $wfac = \r srt:SRT:[] [ww_s38W] case ww_s38W of ds_s38X { __DEFAULT -> case -# [ds_s38X 1#] of sat_s38Y { __DEFAULT -> case $wfac sat_s38Y of ww1_s38Z { __DEFAULT -> *# [ds_s38X ww1_s38Z]; }; }; 0# -> 1#; }; fac = \r srt:SRT:[] [w_s390] case w_s390 of _ { I# ww1_s392 -> case $wfac ww1_s392 of ww2_s393 { __DEFAULT -> I# [ww2_s393]; }; }; I'd expect to get the same with NOINLINE too. First of all, I think this suggests that if my function is big enough (or has some other property and GHCs heuristics decide not to inline) I don't get worker/wrapper. Second, this type of NOINLINEs are very useful for a couple of reasons. For example, let's say I'm benchmarking a function, I NOINLINE the function because I don't want the function to be transformed to something else during the benchmarking, because of inlining and interactions of the function code with the code at the call site (the code that benchmarks). Another example is when looking at the code to see if expected optimizations are done by GHC. I NOINLINE because otherwise I may have to look at dozens of call sites, rather than just one place (the definition). But now I can't reliably do that. So my questions are: Why worker/wrapper is not applied to NOINLINE functions, and how do I fix this? Thanks.

1 0

Re: How does TH know to load non-profiled object code when compiling profiled?
by Edward Z. Yang 08 Jan '16

08 Jan '16

Thanks! In fact, I have just realized that Template Haskell does something very dodgy when it is loading profiled code: it will use the *profiled* interface files (things that are used in splices are brought into scope with import) to figure out what is going on with the *non-profiled* object files. I'm a bit surprised that we haven't had any terrifying bugs related to this. (It should be relatively easy to trigger horrible brokenness; just compile hi and p_hi with different code so that they are inconsistent.) Edward Excerpts from Simon Marlow's message of 2016-01-07 09:42:27 -0800: > On 07/01/2016 16:28, Edward Z. Yang wrote: > > I've been looking for the code that implements this logic, but I can't > > seem to find it. (For what it's worth, compiler plugins *incorrectly* > > load the profiling interface when compiling profiled, which is wrong > > and something I'd like to fix.) Simon Marlow, do you happen to know? > > Yeah, I've been fiddling with this lately. It's this function here: > https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/ghci/L… > > Cheers, > Simon

2 1

Remote GHCi
by Simon Marlow 08 Jan '16

08 Jan '16

Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running interpreted code and the compiler on the same runtime. I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi I'd be interested to hear if anyone has any thoughts around this, particularly if doing this would make your life difficult in some way. Are people relying on dynCompileExpr for anything? Cheers, Simon

9 27

Confused about specified type variables using -XTypeApplications
by Ryan Scott 07 Jan '16

07 Jan '16

I read in the Visible Type Applications paper [1] that you can only apply types to "specified" type variables. However, after trying out -XTypeApplications, I'm confused as to what exactly that means: $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help λ> :set -XTypeInType -XTypeApplications λ> data Prox a = Prox λ> let prox :: Prox a; prox = Prox λ> :t prox @Int prox @Int :: Prox Int λ> :t Prox @Int Prox @Int :: Prox a Huh? For some reason, I'm getting different types for prox @Int and Prox @Int! I think what's happening here is that in Prox @Int, the Int is being applied to a kind variable. That is, it's being applied to the k variable in: Prox :: forall k (t :: k). Prox t But why is this? After all, I don't think I "specified" k anywhere in the definition of Prox, and to make things more confusing, Int gets applied differently in prox @Int (and the definition of prox also doesn't mention k). Is this a bug, or am I misunderstanding something about -XTypeApplications? Ryan S. ----- [1] http://www.cis.upenn.edu/~eir/papers/2016/type-app/visible-type-app.pdf

4 5

Re: How does TH know to load non-profiled object code when compiling profiled?
by Simon Marlow 07 Jan '16

07 Jan '16

On 07/01/2016 16:28, Edward Z. Yang wrote: > I've been looking for the code that implements this logic, but I can't > seem to find it. (For what it's worth, compiler plugins *incorrectly* > load the profiling interface when compiling profiled, which is wrong > and something I'd like to fix.) Simon Marlow, do you happen to know? Yeah, I've been fiddling with this lately. It's this function here: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/ghci/L… Cheers, Simon

1 0

How does TH know to load non-profiled object code when compiling profiled?
by Edward Z. Yang 07 Jan '16

07 Jan '16

I've been looking for the code that implements this logic, but I can't seem to find it. (For what it's worth, compiler plugins *incorrectly* load the profiling interface when compiling profiled, which is wrong and something I'd like to fix.) Simon Marlow, do you happen to know? Edward

1 0

uniqAway and collisions
by Bartosz Nitka 07 Jan '16

07 Jan '16

Hi, I'm running into core lint issues [1] with my determinism patch [2] and they appear to come down to uniqAway coming up with a Unique that's already used in the expression. That creates a collision, making next substitution substitute more than it needs. I have 2 questions: 1. When is it safe to use uniqAway? 2. Is my conclusion reasonable given this trace: (full trace here [3])? I. We start out with (line 123): CallStack (from ImplicitParams): pprSTrace, called at compiler/coreSyn/CoreLint.hs:659:12 in ghc:CoreLint e: EqConstr @ (s_Xpw a_Xpz) @ (s_Xpw b_Xpy) @ s_Xpw @ b_Xpy @ a_Xpz @~ (<s_Xpw a_Xpz>_N :: s_Xpw a_Xpz ~# s_Xpw a_Xpz) @~ (<s_Xpw b_Xpy>_N :: s_Xpw b_Xpy ~# s_Xpw b_Xpy) dt_aq3 fun: EqConstr args: [TYPE: s_Xpw a_Xpz, TYPE: s_Xpw b_Xpy, TYPE: s_Xpw, TYPE: b_Xpy, TYPE: a_Xpz, CO: <s_Xpw a_Xpz>_N, CO: <s_Xpw b_Xpy>_N, dt_aq3] fun_ty: forall a_apr b_aps (s_Xpw :: * -> *) b_Xpy a_Xpz. (a_apr ~# s_Xpw a_Xpz, b_aps ~# s_Xpw b_Xpy) => EqTypes a_Xpz b_Xpy -> EqTypes a_apr b_aps II. Then we create s_Xpz with uniqAway (line 499) which has the same unique as a_Xpz above CallStack (from ImplicitParams): pprSTrace, called at compiler/types/TyCoRep.hs:1947:5 in ghc:TyCoRep old_var: s_Xpy new_var: s_Xpz III. Which causes trouble when we want to substitute s_Xpw for s_Xpz and we substitute a_Xpz as well (line 733): CallStack (from ImplicitParams): pprSTrace, called at compiler/coreSyn/CoreLint.hs:813:11 in ghc:CoreLint substTyWith [tv] [arg_ty] body_ty forall b_XpB a_XpD. (s_Xpw s_Xpw ~# s_Xpw a_XpD, s_Xpw b_Xpy ~# s_Xpw b_XpB) => EqTypes a_XpD b_XpB -> EqTypes (s_Xpw s_Xpw) (s_Xpw b_Xpy) The uniqAway comes from substTyVarBndrCallback which blames to nokinds patch. Thanks, Bartosz [1] https://phabricator.haskell.org/P77 [2] https://phabricator.haskell.org/P76 [3] https://phabricator.haskell.org/P78

3 5

latest symlink
by Joachim Breitner 07 Jan '16

07 Jan '16

Hi, https://downloads.haskell.org/~ghc/latest/ still points to https://downloads.haskell.org/~ghc/7.10.2/ and not https://downloads.haskell.org/~ghc/7.10.3/ Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

4 5

expandTypeSynonyms panics after kind equality patch
by Ömer Sinan Ağacan 07 Jan '16

07 Jan '16

My branch panicking during stage 2 build and when I tried to debug I realized the panicking function is `unionTCvSubst`, when called by `expandTypeSynonyms`. In my branch I'm doing some type-based transformations and I'm using `expandTypeSynonyms` on type of identifiers for that. According to git blame logs, the function `unionTCvSubst` was added with kind equality patch. The patch made this change in `expandTypeSynonyms`: - = go (mkAppTys (substTy (mkTopTvSubst tenv) rhs) tys') + = let subst' = unionTCvSubst subst (mkTopTCvSubst tenv) in + go subst' (mkAppTys rhs tys') Which is what's causing the panic. The exact place it's panicking during the stage2 build is when I call `expandTypeSynonyms` on type `TvSubstEnv` (i.e. in my transformation I get type of an id and it turns out to be TvSubstEnv, when I call `expandTypeSynonyms` on this type it panics) I figured this much but I don't understand type system details, so, does anyone here have any ideas what's going wrong here? Richard? Note that this panic happens even though I don't do any changes in types - I'm just looking at the types for some transformations but no changes on the types are done.

2 1