Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,931
    • Issues 4,931
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 464
    • Merge requests 464
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #17409
Closed
Open
Created Oct 28, 2019 by Sebastian Graf@sgraf812Developer

Simplifier bug in 8.6.5 which appears to be fixed in 8.8.1

Alexis King writes:

Hi all,

I have an odd question: I’ve bumped into a clear simplifier bug, and although it only happens on GHC 8.6.5, not 8.8.1, I’d like to locate the change that fixed it. My library’s test suite currently fails on GHC 8.6.5 due to the bug, and I’d rather not force all my users to upgrade to 8.8 if I can help it, so I’m hoping to find a workaround.

The minimal test case I’ve found for the bug is this program:

    {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving, TypeFamilies #-}

    import Control.Exception
    import Control.Monad.IO.Class
    import Control.Monad.Trans.Identity
    import Control.Monad.Trans.Reader

    class Monad m => MonadFoo m where
      foo :: m a -> m a
    instance MonadFoo IO where
      foo m = onException m (pure ())
    instance MonadFoo m => MonadFoo (ReaderT r m) where
      foo m = ReaderT $ \r -> foo (runReaderT m r)
    deriving instance MonadFoo m => MonadFoo (IdentityT m)

    type family F m where
      F m = IdentityT m

    newtype FT m a = FT { runFT :: F m a }
      deriving (Functor, Applicative, Monad, MonadIO, MonadFoo)

    main :: IO ()
    main = run (foo (liftIO (throwIO (IndexOutOfBounds "bang"))))
      where
        run :: ReaderT () (FT (ReaderT () IO)) a -> IO a
        run = flip runReaderT () . runIdentityT . runFT . flip runReaderT ()

Using GHC 8.6.5 on macOS 10.14.5, compiling this program with optimizations reliably triggers the -fcatch-bottoms sanitization:

    $ ghc -O -fcatch-bottoms weird.hs && ./weird
    [1 of 1] Compiling Main             ( weird.hs, weird.o )
    Linking weird ...
    weird: Bottoming expression returned

What goes wrong? Somehow the generated core for this program includes the following:

    lvl_s47B :: SomeException
    lvl_s47B = $fExceptionArrayException_$ctoException lvl_s483

    m_s47r :: () -> State# RealWorld -> (# State# RealWorld, () #)
    m_s47r
      = \ _ (eta_B1 :: State# RealWorld) -> raiseIO# lvl_s47B eta_B1

    main_s2Ww :: State# RealWorld -> (# State# RealWorld, () #)
    main_s2Ww
      = \ (eta_a2wK :: State# RealWorld) ->
          catch# (case m_s47r `cast` <Co:33> of { }) raiseIO# eta_a2wK

This core is completely bogus: it assumes that m_s47r is bottom, but m_s47r is a top-level function! The program still passes -dcore-lint, unfortunately, as it is still well-typed. (Also, in case it helps: -ddump-simplifier-iterations shows that the buggy transformation occurs in the first iteration of the very first simplifier pass.)

I’ve been trying to figure out what change might have fixed this so that I can assess if it’s possible to work around, but I haven’t found anything obvious. I’ve been slowly git bisecting to look for the commit that introduced the fix, but many of the commits I’ve tested cause unrelated panics on my machine, which has been exacerbating the problem of the slow recompilation times. I’m a little at wits’ end, but opening a bug report hasn’t felt right, since the bug does appear to already be fixed.

Does this issue ring any bells to anyone on this list? Is there a particular patch that landed between GHC 8.6.5 and GHC 8.8.1 that might have fixed this problem? If not, I’ll keep trying with git bisect, but I’d appreciate any pointers.

Thanks, Alexis

Edited Oct 28, 2019 by Simon Peyton Jones
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking