1. 11 Mar, 2016 5 commits
  2. 10 Mar, 2016 1 commit
    • Sergei Trofimovich's avatar
      fix Float/Double unreg cross-compilation · c42cdb7f
      Sergei Trofimovich authored
      Looking at more failures on m68k (Trac #11395)
      I've noticed the arith001 and arith012 test failures.
      (--host=x86_64-linux --target=m68k-linux).
      
      The following example was enough to reproduce a problem:
      
          v :: Float
          v = 43
          main = print v
      
      m68k binaries printed '0.0' instead of '43.0'.
      
      The bug here is how we encode Floats and Double
      as Words with the same binary representation.
      
      Floats:
        Before the patch we just coerced Float to Int.
        That breaks when we cross-compile from
        64-bit LE to 32-bit BE.
      
        The patch fixes conversion by accounting for padding.
        when we extend 32-bit value to 64-bit value (LE and BE
        do it slightly differently).
      
      Doubles:
        Before the patch Doubles were coerced to a pair of Ints
        (not correct as x86_64 can hold Double in one Int) and
        then trucated this pair of Ints to pair of Word32.
      
        The patch fixes conversion by always decomposing in
        Word32 and accounting for host endianness (newly
        introduced hostBE)  and target endianness (wORDS_BIGENDIAN).
      
      I've tested this patch on Double and Float conversion on
          --host=x86_64-linux --target=m68k-linux
      crosscompiler. It fixes 10 tests related to printing Floats
      and Doubles.
      
      Thanks to Bertram Felgenhauer who poined out this probem.
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Test Plan: checked some examples manually, fixed 10 tests in test suite
      
      Reviewers: int-e, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1990
      
      GHC Trac Issues: #11395
      c42cdb7f
  3. 09 Mar, 2016 3 commits
  4. 08 Mar, 2016 4 commits
  5. 07 Mar, 2016 3 commits
  6. 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
  7. 05 Mar, 2016 6 commits
  8. 04 Mar, 2016 2 commits
  9. 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
  10. 01 Mar, 2016 5 commits
  11. 29 Feb, 2016 8 commits