[GHC] #11126: Entered absent arg in a Repa program

[GHC]

#11126: Entered absent arg in a Repa program
-------------------------------------+-------------------------------------
        Reporter:  tuplanolla        |                Owner:
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by jscholl):

 I have a theory what is happening here:

 The important values here are {{{arr2}}} and some value called {{{get}}}.
 In the original definition {{{get}}} evaluates {{{arr2}}} and uses some
 component of it. Now {{{arr2}}} just is some tuple type ({{{ADelayed}}})
 with two lazy fields. It is constructed by evaluating another value
 {{{arr}}} and then building this tuple. The second field of the tuple is
 just a thunk. So the simplifier inlines {{{arr2}}} in {{{get}}} and thus
 avoids building the tuple thing of {{{arr2}}}. Now the last reference to
 {{{arr2}}} was dropped. In the next run the simplifier replaces {{{arr2}}}
 with {{{absentError}}}. Shortly after that a reference to {{{arr2}}}
 appears again in the code. So what went wrong? {{{get}}} had an unfolding!
 In this unfolding it mentions {{{arr2}}} and the simplifier spots a
 position where it wants to inline {{{get}}}. Now we have a reference to
 {{{arr2}}} again because the unoptimized version of {{{get}}} is inlined.
 But this time we will optimize in a different way as {{{arr2}}} was
 incorrectly changed to {{{absentError}}}.

 So the main question would be: Does the compiler consider unfoldings when
 determining whether a value is unused and thus can be replaced by
 {{{absentError}}}? If not this could be the culprit. Sadly the bug relies
 on a very specific order of events in the compiler, so it will be hard to
 find a smaller test case for this.

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