#15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): So here's a hint. The documentation to `unsafeUseAsCString` mentions this:
After calling this function the `CString` shares the underlying byte buffer with the original `ByteString`. Thus **modifying the `CString`**, either in C, or **using poke**, will cause the contents of the `ByteString` to change, **breaking referential transparency**. Other `ByteStrings` created by sharing (such as those produced via 'take' or 'drop') will also reflect these changes. Modifying the `CString` will break referential transparency. To avoid this, use `useAsCString`, which makes a copy of the original `ByteString`.
(emphasis mine). And then in the `fasta/Main.hs` source code, we see this: {{{#!hs unsafeUseAsCString line $ \ptr -> do --- snip --- plusPtr ptr i `poke` unsafeIndex lookupTable newseed --- snip --- }}} In other words, `fasta` does exactly what the documentation says not to do. Which would suggest that the state hack itself isn't really to blame, it just causes different sharing behavior. I'll run a few tests to get more certainty here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15225#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler