- ghc-devs - Haskell.org

RE: Another strictness analysis wrinkle
by David Feuer 15 Mar '17

15 Mar '17

Actually, I just had a thought. What if we ran ST computations with a different state token type? Say, State# FakeWorld? Would that let them escape the hack? David FeuerWell-Typed, LLP -------- Original message --------From: David Feuer <david(a)well-typed.com> Date: 3/15/17 6:38 AM (GMT-05:00) To: GHC developers <ghc-devs(a)haskell.org> Subject: Another strictness analysis wrinkle I don't see how we can take advantage of this, but IO and ST seem quite different from a strictness analysis perspective. The whole I/O hack is completely unnecessary for ST. Ugh. David FeuerWell-Typed, LLP

1 0

Another strictness analysis wrinkle
by David Feuer 15 Mar '17

15 Mar '17

I don't see how we can take advantage of this, but IO and ST seem quite different from a strictness analysis perspective. The whole I/O hack is completely unnecessary for ST. Ugh. David FeuerWell-Typed, LLP

1 0

RE: [GHC] #13413: GHC HEAD panic: collectNBinders
by Simon Peyton Jones 15 Mar '17

15 Mar '17

I know what is going on here. I'm in a meeting all day, but I hope to fix tomorrow. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 11 March 2017 20:12 | Cc: ghc-tickets(a)haskell.org | Subject: [GHC] #13413: GHC HEAD panic: collectNBinders | | #13413: GHC HEAD panic: collectNBinders | -------------------------------------+---------------------------------- | -------------------------------------+--- | Reporter: RyanGlScott | Owner: (none) | Type: bug | Status: new | Priority: highest | Milestone: 8.2.1 | Component: Compiler | Version: 8.1 | Keywords: JoinPoints | Operating System: | Unknown/Multiple | Architecture: | Type of failure: GHC rejects | Unknown/Multiple | valid program | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Wiki Page: | -------------------------------------+---------------------------------- | -------------------------------------+--- | `repa-eval-4.2.3.1` currently fails to build on GHC HEAD because of this | issue. Trying to build it leads to several `collectNBinders` panics is | various modules. You can reproduce this by compiling this module: | | {{{#!hs | {-# LANGUAGE BangPatterns #-} | {-# LANGUAGE MagicHash #-} | module Data.Repa.Eval.Generic.Seq.Chunked where | | import GHC.Exts (Int#, (+#), (*#), (>=#)) | | ------------------------------------------------------------------------ | ------- | -- | Fill a block in a rank-2 array, sequentially. | -- | -- * Blockwise filling can be more cache-efficient than linear filling | for | -- rank-2 arrays. | -- | -- * The block is filled in row major order from top to bottom. | -- | fillBlock2 | :: (Int# -> a -> IO ()) -- ^ Update function to write into | result buffer. | -> (Int# -> Int# -> a) -- ^ Function to get the value at an (x, | y) index. | -> Int# -- ^ Width of the whole array. | -> Int# -- ^ x0 lower left corner of block to | fill. | -> Int# -- ^ y0 | -> Int# -- ^ w0 width of block to fill | -> Int# -- ^ h0 height of block to fill | -> IO () | | fillBlock2 | write getElem | !imageWidth !x0 !y0 !w0 h0 | | = do fillBlock y0 ix0 | where !x1 = x0 +# w0 | !y1 = y0 +# h0 | !ix0 = x0 +# (y0 *# imageWidth) | | {-# INLINE fillBlock #-} | fillBlock !y !ix | | 1# <- y >=# y1 = return () | | otherwise | = do fillLine1 x0 ix | fillBlock (y +# 1#) (ix +# imageWidth) | | where {-# INLINE fillLine1 #-} | fillLine1 !x !ix' | | 1# <- x >=# x1 = return () | | otherwise | = do write ix' (getElem x y) | fillLine1 (x +# 1#) (ix' +# 1#) | | {-# INLINE [0] fillBlock2 #-} | }}} | | This compiles on GHC 8.0.2, but on GHC HEAD: | | {{{ | $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs | [1 of 1] Compiling Data.Repa.Eval.Generic.Seq.Chunked ( Bug.hs, Bug.o ) | ghc-stage2: panic! (the 'impossible' happened) | (GHC version 8.1.20170201 for x86_64-unknown-linux): | collectNBinders | 2 | Call stack: | CallStack (from HasCallStack): | prettyCurrentCallStack, called at | compiler/utils/Outputable.hs:1179:58 in ghc:Outputable | callStackDoc, called at compiler/utils/Outputable.hs:1183:37 in | ghc:Outputable | pprPanic, called at compiler/coreSyn/CoreSyn.hs:1970:25 in | ghc:CoreSyn }}} | | Interestingly, compiling this triggers the panic at any optimization | level, but loading the module into GHCi does not cause it to panic. | | This regression was introduced in | 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 | (Join points). | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13413> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler

1 0

Removing core-spec.pdf from repository?
by Ben Gamari 14 Mar '17

14 Mar '17

Hello everyone, Currently there is a typeset copy of the Core specification in the GHC repository. This means any time someone changes the specification the repository grows by around 300kB. While this isn't the end of the world, it's generally considered bad form to put generated files under version control. Of course, the tools required to typeset the specification (ott and LaTeX) are non-trivial to install, so there is considerable convenience that comes from having a typeset version readily available. I suggest that we remove the PDF from the repository but instead I can start including it in my nightly documentation builds. Any objections? Cheers, - Ben

8 8

RE: Removing core-spec.pdf from repository?
by David Feuer 13 Mar '17

13 Mar '17

Kill it! That's terrible practice indeed. Speaking of generated files, it's time to check if our Unicode tables are up to date. David FeuerWell-Typed, LLP -------- Original message --------From: Ben Gamari <ben(a)well-typed.com> Date: 3/13/17 6:57 PM (GMT-05:00) To: GHC developers <ghc-devs(a)haskell.org> Subject: Removing core-spec.pdf from repository? Hello everyone, Currently there is a typeset copy of the Core specification in the GHC repository. This means any time someone changes the specification the repository grows by around 300kB. While this isn't the end of the world, it's generally considered bad form to put generated files under version control. Of course, the tools required to typeset the specification (ott and LaTeX) are non-trivial to install, so there is considerable convenience that comes from having a typeset version readily available. I suggest that we remove the PDF from the repository but instead I can start including it in my nightly documentation builds. Any objections? Cheers, - Ben

1 0

Trac password change interface restored
by Ben Gamari 13 Mar '17

13 Mar '17

Hello everyone, For the last few weeks Trac's password change functionality has been disabled due to passwords being leaked through the ghc-tickets mailing list. I have updated the Trac configuration to fix this leakage and reenabled this interface. Moreover, we shouldn't see any further email address verifications messages on ghc-tickets. Thanks to everyone for their patience while this was handled. Cheers, - Ben

1 0

What should and should not be marked has_side_effects?
by David Feuer 11 Mar '17

11 Mar '17

Note [PrimOp can_fail and has_side_effects] in prelude/PrimOp.hs says > A primop "has_side_effects" if it has some *write* effect, visible > elsewhere > > - writing to the world (I/O) > - writing to a mutable data structure (writeIORef) > - throwing a synchronous Haskell exception > > [...] > > * NB3: *Read* effects (like reading an IORef) don't count here, > > because it doesn't matter if we don't do them, or do them more than > once. *Sequencing* is maintained by the data dependency of the state > token. But this does not actually seem to match what goes on in primops.txt.pp. The following, among many other seemingly read-only operations, have has_side_effects = True: readMutVar# (the very example cited!), readArray#, unsafeFreezeArray#, unsafeThawArray#, tryReadMVar#, deRefWeak# So what's the correct story? Do we want to change the note, or change the reality? The reason I happen to be looking at this is that I think the current arrangement allows us to define unsafeInterleaveIO in a particularly simple fashion: unsafeInterleaveIO = pure . unsafePerformIO but that's only safe as long as the interleaved IO won't float out and get performed before it's forced by normal IO. But the unsafeInterleaveIO story seems much less important, in the grand scheme of things, than making everything else run fast. If indeed it's otherwise safe to mark these read-only ops has_side_effects=False, then I imagine we probably should do that. David Feuer

2 1

New commits
by Simon Peyton Jones 10 Mar '17

10 Mar '17

Edward, Ben, others I have just pushed a patch series 2209d5e6 Comments only 4eeb3273 Drop redundant import 2d3cb34a Define TcSimplify.simplifyTopImplic and use it af6ed4a6 Fix constraint simplification in rules 48d1866e Improve error messages for skolems 7e96526a Fix TcSimplify.decideQuantification for kind variables bc0f3abd Deal with JoinIds before void types 900cfdc2 Do not generate a data-con wrapper for !Int# Issues: * bkpcabal03 is failing... I don't see how it can possibly have anything to do with me, so I've pushed anyway. Edward, might you look? * I get these stat failures - all improvements perf/compiler/T13035.run T13035 [stat too good] (normal) perf/compiler/T12425.run T12425 [stat too good] (optasm) perf/compiler/T9675.run T9675 [stat too good] (optasm) perf/space_leaks/T4029.run T4029 [stat too good] (ghci) perf/should_run/T10359.run T10359 [stat too good] (normal) perf/compiler/T1969.run T1969 [stat too good] (normal) Some of them are from before (I reported this and suggested re-centreing the numbers), but the last two are new, I think. Hurrah! Ben: might you look? Sorry for playing a bit fast and loose, but I'm out of time, and there are bug-fixes in here. Thanks Simon bkpcabal03 simonpj@cam-05-unx:~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03$ make bkpcabal03 rm -f -r tmp.d inst dist Setup make -s --no-print-directory clean '/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-pkg' init tmp.d '/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2' -v0 --make Setup cp bkpcabal03.cabal.in1 bkpcabal03.cabal # typecheck asig1 (cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "asig1" asig1) (cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build) (cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 copy) (cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 register) # typecheck asig2 (cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "asig2" asig2) (cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build) (cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 copy) (cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 register) # typecheck top-level '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "toplevel" bkpcabal03 ! '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build <no location info>: warning: [-Wmissing-home-modules] Modules are not listed in command line: Foo Mod.hs:4:5: error: Variable not in scope: g :: Int # modify mixins cp bkpcabal03.cabal.in2 bkpcabal03.cabal # retypecheck top-level '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "toplevel" bkpcabal03 '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build <no location info>: warning: [-Wmissing-home-modules] Modules are not listed in command line: Foo simonpj@cam-05-unx:~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03$ dirs ~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03 ~/5builds/HEAD-5 ~/code/HEAD-5 simonpj@cam-05-unx:~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03$

2 1

Windows
by Simon Peyton Jones 10 Mar '17

10 Mar '17

Windows build is working again....thank you! (To be fair, I'm still building stage2, so have not tried the testsuite yet, but I live in hope.) Simon

1 0

FW: GHC on Windows 10 15019+
by Simon Peyton Jones 10 Mar '17

10 Mar '17

Phyx and friends: does this ring a bell? Do we have a ticket? -----Original Message----- From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of J. Garrett Morris Sent: 09 March 2017 17:54 To: GHC users <glasgow-haskell-users(a)haskell.org> Subject: GHC on Windows 10 15019+ Hi y'all, I've recently run into a problem using released version of GHC on Windows 10, builds 15019 and later. The problem seems to be an incompatibility with Mingw64---builds fail calling realgcc.exe with vaguely incomprehensible error messages (Program failed to start with error 0xc0000142). Replacing the packaged version of Mingw64 with a more recent build (from Msys2, say) restores functioning, but no longer works if there are spaces in the path to GHC. I've observed this on three different machines, so I don't think it's just a configuration oddity. Has anyone else encountered similar problems, or can anyone else verify? If so, it might be worth repackaging at least the latest released version with a more recent Mingw64. /g -- Prosperum ac felix scelus virtus vocatur -- Seneca The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

2 1