With Phab:D2525 I have not seen the panic in `mkFastStringWith` described in #12537 anymore. I rebuilt Stackage nightly twice on a
#12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:16 trommler]: powerpce64le. Another rebuild yielded one panic in `mkFastStringWith`. So it was a bit to early to declare victory :-( The situation has improved though. Previously I saw a handful of packages out of 1900 fail with that panic and now it is only one in around 4000 builds. My theory is that the write barrier is not sufficient in a memory model like PowerPC. The write barrier makes sure that the writes before it were performed in main memory before the barrier. But a different processor might still have stale values in its own caches and thus see an inconsistent state. We could insert read (load-load) barriers between the pointer access and data access but that might not be sufficient either. Think of a stale pointer cached in a processor cache that will be loaded before the read barrier will lead to an inconsistent state if data after the barrier comes from main memory. We need to define a semantics for MutVar/Array and then add the necessary barriers, which might compile to nothing depending on the memory model of the target platform. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12469#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler