[ANNOUNCE] GHC 8.6.3 is now available
Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.3, a bugfix release in the GHC 8.6 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.3 The 8.6 release fixes several regressions present in 8.6.2 including: - A code generation bug resulting in segmentations faults in some programs (#15892) - Darwin binary distributions are now correctly built against an in-tree GMP (#15404) - Three bugs leading to linker failures on Windows (#15105, #15894, #15934) - A bug leading to programs with deep stacks crashing when run with retainer profiling enabled (#14758) - A bug resulting in potential heap corruption during stable name allocation (#15906) - Plugins are now loaded during GHCi sessions (#15633) As a few of these issues are rather serious users are strongly encouraged to upgrade. See Trac [1] for a full list of issues resolved in this release. Note that this release ships with one significant but long-standing bug (#14251): Calls to functions taking both Float# and Double# may result in incorrect code generation when compiled using the LLVM code generator. This is not a new issue, it has existed as long as the LLVM code generator has existed; however, changes in code generation in 8.6 made it more likely that user code using only lifted types will trigger it. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed=8.6.3=id=summary=status=type=priority=milestone=component=priority signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: nofib output difference
Hi, now it fail building nofib with a different error: ==nofib== compress: time to compile Uncompress follows... /home/nomeata/logs/ghc-tmp-REV/inplace/bin/ghc-stage2 -O2 -Wno-tabs -Rghc-timing -H32m -hisuf hi -rtsopts -c Uncompress.hs -o Uncompress.o Decode.hs:25:1: error: Main.hs:16:1: error: Encode.hs:9:1: error:Uncompress.hs:15:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 25 | import Defaults | ^^^ Decode.hs:26:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 16 | import Defaults | ^^^ Main.hs:17:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 9 | import Defaults | ^^^ Encode.hs:10:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 15 | import Defaults | ^^^ Uncompress.hs:16:1: error: Could not find module ‘BinConv’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 26 | import BinConv | ^^ Could not find module ‘BinConv’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 17 | import BinConv-- binary conversion routines | ^^ Main.hs:18:1: error: Could not find module ‘PTTrees’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 10 | import PTTrees | ^^ Could not find module ‘BinConv’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 16 | import BinConv-- binary conversion routines | ^^ Uncompress.hs:17:1: error: Could not find module ‘Encode’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 18 | import Encode -- coding routine | ^ Could not find module ‘Decode’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 17 | import Decode -- decoding routines | ^ -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: References for GHC usage of multiple capabilities
Thanks, Tom! I didn't realize that this one was merged into GHC. I wonder if the work presented on Haskell Symposium this year about a libuv-based I/O manager (https://dl.acm.org/citation.cfm?id=3242759) will go somewhere… -- Best, Artem On Fri, 7 Dec 2018 at 12:00 Tom Murphy wrote: > There's also "Mio: A High-Performance Multicore IO Manager for GHC" > > http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf > > On 12/7/18, Artem Pelenitsyn wrote: > > Thanks for heads up, Ben! This is useful stuff to take into account. I > also > > wonder how is this list (mine ++ yours) is relevant to what GHC actually > > has these days. But maybe that's harder to answer quickly. > > > > -- > > Best wishes, > > Artem > > > > > > > > > > On Thu, Dec 6, 2018 at 10:47 AM Ben Gamari wrote: > > > >> Artem Pelenitsyn writes: > >> > >> > Hello devs, > >> > > >> > I've been working on a short survey devoted to a topic of > >> > multithreading > >> > inside the GHC compiler and runtime. So far I was mostly looking at > the > >> > following three papers > >> > > >> > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, > and > >> S. > >> > L. Peyton Jones. Gum: A portable parallel implementation of Haskell. > >> PLDI > >> > ’96 > >> > > >> > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a > >> > shared-memory multiprocessor. Haskell ’05 > >> > > >> > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime > support > >> for > >> > multicore Haskell. ICFP ’09 > >> > > >> > Can you suggest any other papers adding insights on how GHC uses > >> > multiple > >> > capabilities for anything from GC to the implementation of > >> > Parallel/Concurrent Haskell? Perhaps, something more recent than the > >> above, > >> > but preferably published in academic venues. > >> > > >> Here are a few others but I may have missed a few: > >> > >> * Parallel Generational-Copying Garbage Collection with a > >> Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon > >> Peyton Jones) In ISMM '08: Proceedings of the 7th international > symposium > >> on Memory management, Tucson, Arizona, ACM, June 2008 > >> * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn > Finne. > >> * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon > >> Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM > >> SIGPLAN > >> symposium on Principles and practice of parallel programming (PPoPP '05) > >> * Transactional Memory with Data Invariants, Tim Harris and Simon > Peyton > >> Jones. In TRANSACT '06 > >> > >> Cheers, > >> > >> - Ben > >> ___ > >> ghc-devs mailing list > >> ghc-devs@haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: References for GHC usage of multiple capabilities
There's also "Mio: A High-Performance Multicore IO Manager for GHC" http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf On 12/7/18, Artem Pelenitsyn wrote: > Thanks for heads up, Ben! This is useful stuff to take into account. I also > wonder how is this list (mine ++ yours) is relevant to what GHC actually > has these days. But maybe that's harder to answer quickly. > > -- > Best wishes, > Artem > > > > > On Thu, Dec 6, 2018 at 10:47 AM Ben Gamari wrote: > >> Artem Pelenitsyn writes: >> >> > Hello devs, >> > >> > I've been working on a short survey devoted to a topic of >> > multithreading >> > inside the GHC compiler and runtime. So far I was mostly looking at the >> > following three papers >> > >> > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, and >> S. >> > L. Peyton Jones. Gum: A portable parallel implementation of Haskell. >> PLDI >> > ’96 >> > >> > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a >> > shared-memory multiprocessor. Haskell ’05 >> > >> > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime support >> for >> > multicore Haskell. ICFP ’09 >> > >> > Can you suggest any other papers adding insights on how GHC uses >> > multiple >> > capabilities for anything from GC to the implementation of >> > Parallel/Concurrent Haskell? Perhaps, something more recent than the >> above, >> > but preferably published in academic venues. >> > >> Here are a few others but I may have missed a few: >> >> * Parallel Generational-Copying Garbage Collection with a >> Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon >> Peyton Jones) In ISMM '08: Proceedings of the 7th international symposium >> on Memory management, Tucson, Arizona, ACM, June 2008 >> * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn Finne. >> * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon >> Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM >> SIGPLAN >> symposium on Principles and practice of parallel programming (PPoPP '05) >> * Transactional Memory with Data Invariants, Tim Harris and Simon Peyton >> Jones. In TRANSACT '06 >> >> Cheers, >> >> - Ben >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: References for GHC usage of multiple capabilities
Thanks for heads up, Ben! This is useful stuff to take into account. I also wonder how is this list (mine ++ yours) is relevant to what GHC actually has these days. But maybe that's harder to answer quickly. -- Best wishes, Artem On Thu, Dec 6, 2018 at 10:47 AM Ben Gamari wrote: > Artem Pelenitsyn writes: > > > Hello devs, > > > > I've been working on a short survey devoted to a topic of multithreading > > inside the GHC compiler and runtime. So far I was mostly looking at the > > following three papers > > > > [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, and > S. > > L. Peyton Jones. Gum: A portable parallel implementation of Haskell. > PLDI > > ’96 > > > > [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a > > shared-memory multiprocessor. Haskell ’05 > > > > [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime support > for > > multicore Haskell. ICFP ’09 > > > > Can you suggest any other papers adding insights on how GHC uses multiple > > capabilities for anything from GC to the implementation of > > Parallel/Concurrent Haskell? Perhaps, something more recent than the > above, > > but preferably published in academic venues. > > > Here are a few others but I may have missed a few: > > * Parallel Generational-Copying Garbage Collection with a > Block-Structured Heap (Simon Marlow, Tim Harris, Roshan P. James, Simon > Peyton Jones) In ISMM '08: Proceedings of the 7th international symposium > on Memory management, Tucson, Arizona, ACM, June 2008 > * Concurrent Haskell, Simon Peyton Jones, Andrew Gordon, Sigbjorn Finne. > * Composable Memory Transactions, Tim Harris, Simon Marlow, Simon > Peyton-Jones, and Maurice Herlihy. In Proceedings of the tenth ACM SIGPLAN > symposium on Principles and practice of parallel programming (PPoPP '05) > * Transactional Memory with Data Invariants, Tim Harris and Simon Peyton > Jones. In TRANSACT '06 > > Cheers, > > - Ben > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: framework failure
Simon Peyton Jones via ghc-devs writes: > I'm getting this > > Framework failures: > >. ./perf/should_run/all.T [] (name 'stats_num_field' is not defined) > I think it comes from this: > > commit fb669f51b3f2cae79511ac3d1c43939d951b1f69 > > Author: Tobias Decking > > Date: Thu Dec 6 15:32:18 2018 -0500 > > Add fusion rules for the zipWith functions in base (#15263) > Yes, it looks like that is the culprit. Looking back at the validation log from when merged this patch, it appears that I observed this too but simply overlooked it. Sorry about that! Fix coming. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
framework failure
I'm getting this Framework failures: . ./perf/should_run/all.T [] (name 'stats_num_field' is not defined) I think it comes from this: commit fb669f51b3f2cae79511ac3d1c43939d951b1f69 Author: Tobias Decking Date: Thu Dec 6 15:32:18 2018 -0500 Add fusion rules for the zipWith functions in base (#15263) Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Cmm Memory Model (Understanding #15449)
FWIW, my main reference at the time when this stuff was implemented was this page by Doug Lea: http://gee.cs.oswego.edu/dl/jmm/cookbook.html As Ben says, things have evolved a lot since then. I'm not an expert at all, but I know from experience that getting this stuff right is really hard. Even on x86 we had a tough time figuring out where to put this barrier: https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2FWSDeque.c$135-137 My understanding of the current memory model is this: - we give no guarantees about ordering between non-atomic IORef operations, except that: doing things in parallel shouldn't segfault". So if a processor can see a pointer in an IORef, it can safely follow the pointer and find the memory it points to correctly initialized. This may require barriers on some architectures, but not x86(_64) as I understand it. - MVar operations and atomicModifyIORef are full barriers. Or something. Cheers Simon On Thu, 29 Nov 2018 at 04:44, Travis Whitaker wrote: > Hello GHC Devs, > > I'm trying to get my head around ticket #15449 ( > https://ghc.haskell.org/trac/ghc/ticket/15449). This gist of things is > that GHC generates incorrect aarch64 code that causes memory corruption in > multithreaded programs run on out-of-order machines. User trommler > discovered that similar issues are present on PowerPC, and indeed ARMv7 and > PowerPC support the same types of load/store reorderings. The LLVM code > emitted by GHC may be incorrect with respect to LLVM's memory model, but > this isn't a problem on architectures with minimal reordering like x86. > > I had initially thought that GHC simply wasn't emitting the appropriate > LLVM fences; there's an elephant-gun-approach here ( > https://github.com/TravisWhitaker/ghc/commits/ghc843-wip/T15449) that > guards each atomic operation with a full barrier. I still believe that GHC > is omitting necessary LLVM fences, but this change is insufficient to fix > the behavior of the test case (which is simply GHC itself compiling a test > package with '-jN', N > 1). > > It seems there's a long and foggy history of the Cmm memory model. Edward > Yang discusses this a bit in his post here ( > http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/) > and issues similar to #15449 have plagued GHC in the past, like #12469 ( > https://ghc.haskell.org/trac/ghc/ticket/12469). Worryingly, GHC only has > MO_WriteBarrier, whereas PowerPC and ARMv7 really need read, write, and > full memory barriers. On ARM an instruction memory barrier might be > required as well, but I don't know enough about STG/Cmm to say for sure, > and it'd likely be LLVM's responsibility to emit that anyway. > > I'm hoping that someone with more tribal knowledge than I might be able to > give me some pointers with regards to the following areas: > > >- Does STG itself have anything like a memory model? My intuition says >'definitely not', but given that STG expressions may contain Cmm operations >(via StgCmmPrim), there may be STG-to-STG transformations that need to care >about the target machine's memory model. >- With respect to Cmm, what reorderings does GHC perform? What are the >relevant parts of the compiler to begin studying? >- Are the LLVM atomics that GHC emits correct with respect to the LLVM >memory model? As it stands now LLVM fences are only emitted for >MO_WriteBarrier. Without fences accompanying the atomics, it seems the LLVM >compiler could float dependent loads/stores past atomic operations. >- Why is MO_WriteBarrier the only provided memory barrier? My hunch is >that it's because this is the only sort of barrier required on x86, which >only allows loads to be reordered with older stores, but perhaps I'm >missing something? Is it plausible that Cmm simply needs additional barrier >primitives to target these weaker memory models? Conversely, is there some >property of Cmm that let's us get away without read barriers at all? > > > Naturally, if I've got any of this wrong or are otherwise barking up the > wrong tree, please let me know. > > Thanks for all your efforts! > > Travis Whitaker > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
