[GHC] #7270: Incorrect optimization with Data.ByteString.append

[GHC]

#7270: Incorrect optimization with Data.ByteString.append
------------------------------------------+---------------------------------
  Reporter:  ocheron                      |          Owner:  duncan          
      Type:  bug                          |         Status:  closed          
  Priority:  highest                      |      Milestone:  7.6.2           
 Component:  libraries (other)            |        Version:  7.6.1           
Resolution:  fixed                        |       Keywords:                  
        Os:  Unknown/Multiple             |   Architecture:  Unknown/Multiple
   Failure:  Incorrect result at runtime  |     Difficulty:  Unknown         
  Testcase:                               |      Blockedby:                  
  Blocking:                               |        Related:                  
------------------------------------------+---------------------------------
Changes (by duncan):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Committed to the upstream bytestring repo. So it'll be fixed in the next
 bytestring point release.

 {{{
 Tue Sep 25 16:21:14 BST 2012  Duncan Coutts <duncan at community.haskell.org>
   * Fix a few incorrect uses of inlinePerformIO
   The incorrect use of inlinePerformIO resulted in multiple calls to
   mallocByteString being shared, and hence two different strings sharing
   the same memory. See http://hackage.haskell.org/trac/ghc/ticket/7270

   Consider:
     foo x = s `seq` r
       where
         r = B.map succ x
         s = B.map succ r

   The B.map function used a pattern like:
     map f (PS fp s len) = inlinePerformIO $ ...
        fp' <- mallocByteString len

   Now, in the foo function above, we have both r and s where the compiler
   can see that the 'len' is the same in both cases, and with
   inlinePerformIO exposing everything, the compiler is free to share the
   two calls to mallocByteString len.

   The answer is not to use inlinePerformIO if we are allocating, but to
 use
   unsafeDupablePerformIO instead. Another reminder that inlinePerformIO is
   really really unsafe, and that we should be using the ST monad instead.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7270#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler