1. 13 Oct, 2015 3 commits
  2. 12 Oct, 2015 5 commits
    • Simon Peyton Jones's avatar
      Reinstate monomorphism-restriction warnings · f8fbf385
      Simon Peyton Jones authored
      This patch is driven by Trac #10935, and reinstates the
      -fwarn-monomorphism-restriction warning.  It was first lost in 2010:
      d2ce0f52 "Super-monster patch implementing the new typechecker -- at
      last"
      
      I think the existing documentation is accurate; it is not even
      turned on by -Wall.
      
      I added one test.
      f8fbf385
    • Simon Peyton Jones's avatar
      Test Trac #10931 · 6b7bad92
      Simon Peyton Jones authored
      6b7bad92
    • Herbert Valerio Riedel's avatar
      base: MRP-refactoring of AMP instances · e737a512
      Herbert Valerio Riedel authored
      This refactors `(>>)`/`(*>)`/`return`/`pure` methods into normal form.
      
      The redundant explicit `return` method definitions are dropped
      altogether.
      
      The explicit `(>>) = (*>)` definitions can't be removed yet, as
      the default implementation of `(>>)` is still in terms of `(*>)`
      (even though that should have been changed according to the AMP but
      wasn't -- see note in GHC.Base for details why this had to be postponed)
      
      A nofib comparision shows this refactoring to result in minor runtime
      improvements (unless those are within normal measurement fluctuations):
      
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
        -------------------------------------------------------------------------
                  Min          -0.0%     -0.0%     -1.6%     -3.9%     -1.1%
                  Max          -0.0%     +0.0%     +0.5%     +0.5%      0.0%
        Geometric Mean         -0.0%     -0.0%     -0.4%     -0.5%     -0.0%
      
      Full `nofib` report at https://phabricator.haskell.org/P68
      
      Reviewers: quchen, alanz, austin, #core_libraries_committee, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1316
      e737a512
    • Erik de Castro Lopo's avatar
      PPC: Fix right shift by 32 bits #10870 · 4bd58c17
      Erik de Castro Lopo authored
      Summary: Test included.
      
      Test Plan: Run test T10870.hs on X86/X86_64/Arm/Arm64 etc
      
      Reviewers: bgamari, nomeata, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1322
      
      GHC Trac Issues: #10870
      4bd58c17
    • Erik de Castro Lopo's avatar
      f0023409
  3. 10 Oct, 2015 7 commits
  4. 09 Oct, 2015 6 commits
  5. 08 Oct, 2015 5 commits
  6. 07 Oct, 2015 2 commits
  7. 06 Oct, 2015 7 commits
  8. 05 Oct, 2015 2 commits
  9. 04 Oct, 2015 2 commits
  10. 03 Oct, 2015 1 commit
    • Tamar Christina's avatar
      Make Windows linker more robust to unknown sections · 620fc6f9
      Tamar Christina authored
      The Windows Linker has 3 main parts that this patch changes.
      
      1) Identification and classification of sections
      2) Adding of symbols to the symbols tables
      3) Reallocation of sections
      
      1.
      Previously section identification used to be done on a whitelisted
      basis. It was also exclusively being done based on the names of the
      sections. This meant that there was a bit of a cat and mouse game
      between `GCC` and `GHC`. Every time `GCC` added new sections there was a
      good chance `GHC` would break. Luckily this hasn't happened much in the
      past because the `GCC` versions `GHC` used were largely unchanged.
      
      The new code instead treats all new section as `CODE` or `DATA`
      sections, and changes the classifications based on the `Characteristics`
      flag in the PE header. By doing so we no longer have the fragility of
      changing section names. The one exception to this is the `.ctors`
      section, which has no differentiating flag in the PE header, but we know
      we need to treat it as initialization data.
      
      The check to see if the sections are aligned by `4` has been removed.
      The reason is that debug sections often time are `1 aligned` but do have
      relocation symbols. In order to support relocations of `.debug` sections
      this check needs to be gone. Crucially this assumption doesn't seem to
      be in the rest of the code. We only check if there are at least 4 bytes
      to realign further down the road.
      
      2.
      The second loop is iterating of all the symbols in the file and trying
      to add them to the symbols table. Because the classification of the
      sections we did previously are (currently) not available in this phase
      we still have to exclude the sections by hand. If they don't we will
      load in symbols from sections we've explicitly ignored the in # 1. This
      whole part should rewritten to avoid this. But didn't want to do it in
      this commit.
      
      3.
      Finally the sections are relocated. But for some reason the PE files
      contain a Linux relocation constant in them `0x0011` This constant as
      far as I can tell does not come from GHC (or I couldn't find where it's
      being set). I believe this is probably a bug in GAS. But because the
      constant is in the output we have to handle it. I am thus mapping it to
      the constant I think it should be `0x0003`.
      
      Finally, static linking *should* work, but won't. At least not if you
      want to statically link `libgcc` with exceptions support. Doing so would
      require you to link `libgcc` and `libstd++` but also `libmingwex`. The
      problem is that `libmingwex` also defines a lot of symbols that the RTS
      automatically injects into the symbol table. Presumably because they're
      symbols that it needs. like `coshf`. The these symbols are not in a
      section that is declared with weak symbols support. So if we ever want
      to get this working, we should either a) Ask mingw to declare the
      section as such, or b) treat all a imported symbols as being weak.
      Though this doesn't seem like it's a good idea..
      
      Test Plan:
      Running ./validate for both x86 and x86_64
      
      Also running the specific test case for #10672
      
      make TESTS="T10672_x86 T10672_x64"
      
      Reviewed By: ezyang, thomie, austin
      
      Differential Revision: https://phabricator.haskell.org/D1244
      
      GHC Trac Issues: #9907, #10672, #10563
      620fc6f9