[GHC] #7411: Exceptions are optimized away in certain situations

[GHC]

#7411: Exceptions are optimized away in certain situations
-------------------------------------+-------------------------------------
        Reporter:  SimonHengel       |                Owner:  tdammers
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.8.1
       Component:  Compiler          |              Version:  7.6.1
      Resolution:                    |             Keywords:  seq, deepseq,
                                     |  evaluate, exceptions
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  Incorrect result  |            Test Case:
  at runtime                         |  simplCore/should_fail/T7411
      Blocked By:                    |             Blocking:
 Related Tickets:  #5129 #15225      |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by tdammers):

 OK, so it turns out that make clean doesn't actually clean things up
 thoroughly enough. I did another test run, building both GHC and nofib
 from a fresh checkout for each run, and now everything works just fine. So
 it seems that the core dumps I got earlier were somehow caused by
 artifacts from a previous build still being in the build tree somewhere;
 clearly if you link things together in ways they weren't meant to, strange
 behavior is to be expected.

 Now armed with that, and a fixed `fasta` implementation from #15225, I
 managed to do six nofib runs; the interesting ones are:

 - Both GHC and nofib compiled with the state hack in place - this is the
 current situation (`nofibrun-gs_ns2.log`)
 - GHC with the state hack, nofib compiled with `-fno-state-hack`
 (`nofibrun-gs-nn2.log`
 - Both GHC and nofib compiled with `-fno-state-hack` (`nofibrun-
 gn_nn2.log`)

 Results from nofib-analyse attached; key takeaway however is that the
 difference overall is small and slightly in favor of removing the state
 hack. A few interesting deviations that stand out:

 - GHC compiled with `-fno-state-hack` consistently produces larger
 binaries, by about 5%
 - Programs compiled with a GHC compiled with `-fno-state-hack` run faster
 by 3.2% on average, but there is a lot of deviation
 - Most of the above improvements seem to be from more efficient GC
 - Compile times differ drastically; vanilla GHC compiling programs with
 `-fno-state-hack` is 23.6% faster on average than the same compiler with
 the state hack; compiling GHC itself with `-fno-state-hack` and then
 compiling the nofib suite also with `-fno-state-hack` is almost 50% faster
 than compiling everything normally. The difference in allocations is even
 more whopping, with 35.5% and 58.3% respectively.

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