1. 09 Mar, 2016 3 commits
  2. 08 Mar, 2016 4 commits
  3. 07 Mar, 2016 3 commits
  4. 06 Mar, 2016 1 commit
    • Sergei Trofimovich's avatar
      Fix minimum alignment for StgClosure (Trac #11395) · ade1a461
      Sergei Trofimovich authored
      The bug is observed on m68k-linux target as crash
      in RTS:
      
          -- a.hs:
          main = print 43
      
          $ inplace/bin/ghc-stage1 --make -debug a.hs
      
          $ ./a
          Program terminated with signal SIGSEGV, Segmentation fault.
          #0  0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858)
              at includes/rts/storage/ClosureMacros.h:248
          (gdb) bt
          #0  0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858)
              at includes/rts/storage/ClosureMacros.h:248
          #1  0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858)
              at includes/rts/storage/ClosureMacros.h:253
          #2  0x80463b6c in LOOKS_LIKE_CLOSURE_PTR (
                  p=0x805aac6e <stg_dummy_ret_closure>)
              at includes/rts/storage/ClosureMacros.h:258
          #3  0x80463e4c in initStorage ()
              at rts/sm/Storage.c:121
          #4  0x8043ffb4 in hs_init_ghc (...)
              at rts/RtsStartup.c:181
          #5  0x80455982 in hs_main (...)
              at rts/RtsMain.c:51
          #6
      
        0x80003c1c in main ()
      
      GHC assumes last 2 pointer bits are tags on 32-bit targets.
      But here 'stg_dummy_ret_closure' address violates the assumption:
      
          LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e <stg_dummy_ret_closure>)
      
      I've added compiler hint for static StgClosure objects to
      align closures at least by their natural alignment (what GHC assumes).
      See Note [StgWord alignment].
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Test Plan: ran basic test on m68k qemu, it got past ASSERTs
      
      Reviewers: simonmar, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1974
      
      GHC Trac Issues: #11395
      ade1a461
  5. 05 Mar, 2016 6 commits
  6. 04 Mar, 2016 2 commits
  7. 02 Mar, 2016 2 commits
    • Simon Peyton Jones's avatar
      Use tyConArity rather than (length tvs) · aea1e5db
      Simon Peyton Jones authored
      A bit more efficient
      aea1e5db
    • Simon Peyton Jones's avatar
      Fix an outright bug in expandTypeSynonyms · 286dc021
      Simon Peyton Jones authored
      The bug was in this code:
      
          go subst (TyConApp tc tys)
            | Just (tenv, rhs, tys') <- expandSynTyCon_maybe tc tys
            = let subst' = unionTCvSubst subst (mkTvSubstPrs tenv) in
              go subst' (mkAppTys rhs tys')
      
      This is wrong in two ways.
       * It is wrong to apply the expanded substitution to tys',
       * The unionTCvSubst is utterly wrong; after all, rhs is
         completely separate, and the union makes a non-idempotent
         substitution.
      
      It was the non-idempotency that gave the Lint failure in Trac #11665,
      when there was a type synonym whose RHS mentioned another type synonym,
      something like
      
        type T a b = a -> b
        type S x y = T y x
      
      It only affects SpecConstr because that's about the only place where
      expandTypeSyonym is called.  I tried to trigger the failure with a
      simple test case, but failed, so I have not added a regression test.
      
      Fortunately the solution is very simple and solid.
      
      FWIW, the culprit was 674654, "Add kind equalities to GHC".
      286dc021
  8. 01 Mar, 2016 5 commits
  9. 29 Feb, 2016 10 commits
  10. 27 Feb, 2016 4 commits