[GHC] #15225: `-fno-state-hack` produces incorrect results in nofib

[GHC]

#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