- ghc-devs - Haskell.org

Temporarily pinning a thread to a capability
by Edward Kmett 28 Oct '15

28 Oct '15

Would anything go wrong with a thread id if I pinned it to a capability after the fact? I could in theory do so just by setting tso->flags |= TSO_LOCKED and then disabling this later by restoring the TSO flags. I can't think of anything but I figured folks here might be able to think of invariants I don't know about. Usage scenario: I have a number of things where I can't afford a map from a ThreadId# or even its internal id to a per-thread value for bounded wait-free structures. On the other hand, I can afford one entry per capability and to make a handful of primitives that can't be preempted, letting me use normal writes, not even a CAS, to update the capability-local variable in a primitive (indexing into an array of size based on the number of capabilities). This lets me bound the amount of "helpers" to consider by the capability count rather than the potentially much larger and much more variable number of live threads. However, I may need to access this stuff in "pure" code that wasn't written with my needs in mind, so I need to at least temporarily pin the current thread to a fixed capability for the duration when that happens. This isn't perfect, it won't react to a growing number of capabilities nicely in the future, but it does handle a lot of things I can't do now at all without downgrading to lock-free and starving a lot of computations, so I'm hoping the answer is "it all works". =) -Edward

3 4

GADT decls
by Simon Peyton Jones 28 Oct '15

28 Oct '15

Ahh. I think I get it. The trouble is that ConDecl doesn’t have the same structure as what the user wrote. Maybe we should just fix that? How about this declaration? Would that make the annotations easier? Ie simple and routine. Simon data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- After the ‘::’ , con_doc :: Maybe LHsDocString , con_old_rec :: Bool } | ConDeclH98 { con_name :: Located name , con_implict :: HsImplicitBndrs () -- ^ Implicit binders, added by renamer , con_qvars :: Maybe [LHsTyVarBndr name] -- User-written foralls (if any) , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com] Sent: 27 October 2015 21:36 To: Simon Peyton Jones Subject: Re: dll-split The problem comes in mkGadtDecl, I am pretty sure. If I compare your branch to master, I see that the old one was mkGadtDecl :: [Located RdrName] -> LHsType RdrName -- Always a HsForAllTy -> P ([AddAnn], ConDecl RdrName) mkGadtDecl names (L l ty) = do let (anns,ty') = flattenHsForAllTyKeepAnns ty gadt <- mkGadtDecl' names (L l ty') return (anns,gadt) where the flattenHsForAllTyKeepAnns explicitly pulls out annotations that will get lost when the original type gets broken apart and re-assembled as a ConDecl for the GADT. I do recall having to exercise particular care in this area the first time around, because of the way the original type is turned into a GADT constructor. If this does not help, I can try and dive into what you are doing in more detail tomorrow afternoon some time. Alan On Tue, Oct 27, 2015 at 11:22 PM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Thanks. But why?! Here’s my reasoning, looking at Parser.y • The RHS of the GADT signature is a ‘ctype’ • That parses the “forall v a.” , and then goes to type, then btype, then atype • Now we get to the production ‘(‘ ctype ‘)’ in atype • And that has mop and mcp to record the location of the parens. It all looks right to me. But NB that now HsForAllTy and HsQualTy are split, so the parens will be attached to the HsQualTy sub-structure. Does that make a difference? Simon From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com<mailto:alan.zimm@gmail.com>] Sent: 27 October 2015 21:04 To: Simon Peyton Jones Subject: Re: dll-split I have run the tests on your branch, and can report the following for the failing API annotations tests . T10268 [bad stdout] (normal) - Benign . T10354 [bad stdout] (normal) - Benign . T10396 [bad stdout] (normal) - Benign . T10399 [bad stdout] (normal) - Problem . listcomps [bad stdout] (normal) - Benign For T10399 the problem is the following are missing (AK Test10399.hs:(16,5)-(17,69) AnnCloseP = [Test10399.hs:17:69]) (AK Test10399.hs:(16,5)-(17,69) AnnOpenP = [Test10399.hs:16:27]) These are the outer parens in SetTo4 after the forall : data MaybeDefault v where SetTo :: forall v . ( Eq v, Show v ) => !v -> MaybeDefault v SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v -> a -> MaybeDefault [a]) I will be documenting the check-api-annotations usage soon, and as part of that will clean it up so that it does not emit gratuitous changes that are benign. Regards Alan On Tue, Oct 27, 2015 at 11:21 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Incidentally, Alan, on this particular branch I have some api-annotations failures that I can’t figure out (lacking the user manual that you are writing). I wonder if you could help. Could you possibly build that branch for yourself too? wip/spj-wildcard-refactor Then I can ask you specifics and you’ll have a working branch to poke at. Thanks! Simon From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com<mailto:alan.zimm@gmail.com>] Sent: 27 October 2015 09:12 To: Simon Peyton Jones Cc: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>; Ben Gamari Subject: Re: dll-split I think you need to remove Ctype and Lexer from https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com…> On 27 Oct 2015 11:06 AM, "Simon Peyton Jones" <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: It’s just not my day. Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure in dll-split! Should dll-split be running at all on Linux???? The output it produces is below. I’m totally stuck. Help desperately needed. Simon inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastFunctions FastMutInt FastString FastStringEnv FieldLabel Fingerprint FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream" Reachable modules from DynFlags out of date Please fix compiler/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.mk&data…>, or building DLLs on Windows may break (#7780) Redundant modules: Ctype Lexer simonpj@cam-05-unx:~/5builds/HEAD-2$ _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskel…>

2 1

RE: Type-level error messages
by Simon Peyton Jones 28 Oct '15

28 Oct '15

I’ve forgotten the state of your type-level error messages work. How’s it going? I think we should try to add it to 8.0.1. The current status is that the idea is implemented on a branch. Then, there were some comments and suggestions that maybe we should do things in a different way, implementation wise. I haven't had a chance to look into these in detail, or implement them, and as far as I know nobody else has stepped up to make the changes. So we could simply go with the current version, and if for some reason we want to change the implementation we could do it later, as I don't think the API will be affected in any way. When do the changes need to happen by, so that it makes it in 8.0? I have been a bit busy, but I could probably find some time to make whatever changes are required for this to be merged. OK good! In that case · Add it to the hoped-for features in the GHC 8.01. status page · Write a wiki page with a specification · Announce the proposal and seek feedback · Meanwhile make sure the branch reflects what you want to be in it If you don’t have time, well, no harm done… any progress you make on the above will still be useful. Simon From: Iavor Diatchki [mailto:iavor.diatchki@gmail.com] Sent: 22 October 2015 17:42 To: Simon Peyton Jones Cc: Augustsson, Lennart Subject: Re: Type-level error messages Hello, I think we should try to add it to 8.0.1. The current status is that the idea is implemented on a branch. Then, there were some comments and suggestions that maybe we should do things in a different way, implementation wise. I haven't had a chance to look into these in detail, or implement them, and as far as I know nobody else has stepped up to make the changes. So we could simply go with the current version, and if for some reason we want to change the implementation we could do it later, as I don't think the API will be affected in any way. When do the changes need to happen by, so that it makes it in 8.0? I have been a bit busy, but I could probably find some time to make whatever changes are required for this to be merged. -Iavor On Thu, Oct 22, 2015 at 3:47 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Iavor I’ve forgotten the state of your type-level error messages work. How’s it going? It’s not mentioned on https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1: shouldn’t it be? Simon

5 8

dns issues with ghc.haskell.org
by lennart spitzner 28 Oct '15

28 Oct '15

hi, This mail is intended for the maintainers of ghc.haskell.org who i can hopefully reach on this list. Once more i run into the issue that firefox resolves ghc.haskell.org to the wrong (an outdated?) ip address (resulting in some 500 Internal Server Error page; i guess on some other server..). When switching to a different browser the address is resolved "correctly" and i reach the expected server. For me personally this is only slightly annoying, but another fellow on irc recently reported the same symptoms, so i am not the only one affected. Might be worth resolving. I have not observed a failure of this kind for any other server. I don't really know what could be the issue or how to diagnose this further. If it helps, in this case (have not checked when this occurred previously): "wrong" address 162.242.239.16 "correct" 104.25.122.13 Lennart

2 1

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

27 Oct '15

Hi everyone! Do you know, if there is pragma for warning suppression? I want to implement something like warning suppression related to this ticket in GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602) Or i need to implement that kind of pragma by myself? Thanks in advance! Edgar

6 16

unboundKey and fromIntegerClassOpKey unique overlap?
by Ben Gamari 27 Oct '15

27 Oct '15

Hello everyone, I noticed while looking through PrelNames that unboundKey and fromIntegerClassOpKey appear to share a unique in the master branch. Is this safe/expected? Cheers, - Ben

2 1

New error on linux
by Simon Peyton Jones 27 Oct '15

27 Oct '15

Clean build on HEAD on Linux is now giving a new error. Actual stderr output differs from expected: --- ./driver/T10970a.stderr.normalised 2015-10-27 09:44:02.279188078 +0000 +++ ./driver/T10970a.comp.stderr.normalised 2015-10-27 09:44:02.279188078 +0000 @@ -1,6 +1,4 @@ T10970a.hs:4:0: missing binary operator before token "(" - #if MIN_VERSION_base(3,0,0) - ^ `gcc' failed in phase `C pre-processor'. (Exit code: 1) I figured out the recomp013 problem; there was a commit which interacted badly with link trees commit cdca31ebf7744dcae66a6715500395a63bcc3ee2 Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> Date: Wed Sep 9 22:02:48 2015 -0700 Don't check in autogenerated hs files for recomp013..

3 6

stg_upd_frame_info still broken
by Simon Peyton Jones 27 Oct '15

27 Oct '15

Friends I still cannot build GHC on Windows. On Ben's advice I dumped my current msys setup and re-installed msys64 as described here https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows I cloned an entirely new GHC repository. Then 'sh validate'. Same result as before: any attempt to run GHCi fails with an unresolved symbol. bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info' How could I actually find what the problem is? Trying random things and hoping the problem goes away clearly is not working. Very stuck and deeply frustrated Thanks Simon

3 8

Segfault in a CoreLinted program (and a GHC-generated Core question)
by Ömer Sinan Ağacan 27 Oct '15

27 Oct '15

I have a very simple Core plugin that generates some functions. After my Core-to-Core pass is done, I'm running the linter to make sure the Core generated by my plugin is well-formed and well-typed. However, even though lint checker passes, the code generated by my plugin is failing with a segfault. I created a git repo for demonstration: https://github.com/osa1/plugins This is where the CoreLint is happening: https://github.com/osa1/plugins/blob/master/src/Plugins.hs#L38 I'm using GHC HEAD(it doesn't build with 7.10). Here's how to run: Make sure GHC HEAD is in the $PATH, then $ cabal install --with-ghc=ghc-stage2 $ cd test Adding bunch of -ddump parameters here for debugging purposes: $ ghc-stage2 -fplugin=Plugins --make Main.hs -fforce-recomp -ddump-simpl -ddump-ds -ddump-to-file -ddump-stg Now if you run the generated program, it should first print some numbers and then segfault. --- I heard from Simon in various talks(e.g. Haskell exchange 2015) that if lint passes, then there should be no segfaults, so I thought this should be a bug. I'm actually having some other problems with CoreLint too, for example, even though Core lint passes, if I run Core simplifier pass after my plugin runs, GHC is failing with various different panics. Some of those panics are happening inside STG generation, not in simplifier(but it works fine if I disable the simplifier!) It seems like CoreLint is not strict enough, it's not checking some invariants that GHC simplifier and STG code generator are assuming. So my questions are: Am I right in assuming that CoreLint accepted programs should not segfault? What about internal invariants? Should CoreLint check for those? Is there any pass that checks for invariants and prints helpful messages in case of a invariant invalidation? As an attempt at debugging the code generated by my plugin, I wrote the function that is supposed to be generated by my Core pass in Haskell and compiled with GHC. Generated Core is mostly the same, except at one point it has an extra lambda directly applied to a void#, something like ((\_ -> ...) void#). Where can I learn more about why GHC is doing that? Thanks.

5 7

Doc warnings
by Simon Peyton Jones 27 Oct '15

27 Oct '15

I'm getting these warnings relating to the user manual. They seem non-fatal, but are alarming. Simon reading sources... [ 66%] ghc looking for now-outdated files... none found pickling environment... done checking consistency... /5playpen/simonpj/HEAD-2/docs/users_guide/ghc.rst:: WARNING: document isn't included in any toctree done writing... ghc.1 { WARNING: file compiler/simplCore/SimplCore.hs, line 600 Simplifier bailing out after 4 iterations [6069, 1479, 780, 43] Size = {terms: 5,210, types: 10,459, coercions: 2,136} Interesting! A join var that isn't let-no-escaped [$j_snPt] } build succeeded, 1 warning. reading sources... [100%] glasgow_exts WARNING: file compiler/simplCore/SimplEnv.hs, line 528 go_Xn2R WARNING: file compiler/simplCore/SimplEnv.hs, line 528 go_Xn2R looking for now-outdated files... none found pickling environment... done checking consistency... /5playpen/simonpj/HEAD-2/docs/users_guide/ghc.rst:: WARNING: document isn't included in any toctree done preparing documents... done

2 1