1. 09 Oct, 2015 6 commits
  2. 08 Oct, 2015 5 commits
  3. 07 Oct, 2015 2 commits
  4. 06 Oct, 2015 7 commits
  5. 05 Oct, 2015 2 commits
  6. 04 Oct, 2015 2 commits
  7. 03 Oct, 2015 11 commits
    • 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
    • Ben Gamari's avatar
      testsuite: Bump up haddock.base expected allocations · d2fb5328
      Ben Gamari authored
      This started intermittently failing as a result of D1239.
      I suspect this was just the straw that broke the camel's back however.
      d2fb5328
    • Ryan Scott's avatar
      Fill in associated type defaults with DeriveAnyClass · 2f74be9c
      Ryan Scott authored
      Summary:
      Unlike `-XDefaultSignatures`, `-XDeriveAnyClass` would not fill in
      associated type family defaults when deriving a class which contained
      them.
      
      In order to fix this properly, `tcATDefault` needed to be used from
      `TcGenDeriv`. To avoid a module import cycle, `tcATDefault` was moved
      from `TcInstDcls` to `TcClsDcl`.
      
      Fixes #10361.
      
      Test Plan: ./validate
      
      Reviewers: kosmikus, dreixel, bgamari, austin, simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1283
      
      GHC Trac Issues: #10361
      2f74be9c
    • Herbert Valerio Riedel's avatar
      Enable `Enumeration is empty` warnings for `Integer` · 0eb8fcd9
      Herbert Valerio Riedel authored
      This warning was implemented via
      abb3a9fa for addressing #7881. The
      bounded H2010 integral types were handled, but the `Integer` type was
      missed for the enumeration warning.
      
      Fixes #10929
      
      Test Plan: reused T7881 testcase
      
      Reviewers: thomie, bgamari, austin
      
      Reviewed By: thomie, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1305
      
      GHC Trac Issues: #10929
      0eb8fcd9
    • Ryan Scott's avatar
      Make GHC generics capable of handling unboxed types · 6cde981a
      Ryan Scott authored
      This adds a data family (`URec`) and six data family instances (`UAddr`,
      `UChar`, `UDouble`, `UFloat`, `UInt`, and `UWord`) which a `deriving
      Generic(1)` clause will generate if it sees `Addr#`, `Char#`, `Double#`,
      `Float#`, `Int#`, or `Word#`, respectively. The programmer can then
      provide instances for these data family instances to provide custom
      implementations for unboxed types, similar to how derived `Eq`, `Ord`,
      and `Show` instances currently special-case unboxed types.
      
      Fixes #10868.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, dreixel, bgamari, austin, hvr, kosmikus
      
      Reviewed By: dreixel, kosmikus
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1239
      
      GHC Trac Issues: #10868
      6cde981a
    • thomie's avatar
      Testsuite: update expected output for T8602 · a96f1acc
      thomie authored
      a96f1acc
    • thomie's avatar
      Build system: add mk/validate.mk.sample · a3c78abc
      thomie authored
      Reviewers: austin, bgamari
      
      Subscribers: erikd
      
      Differential Revision: https://phabricator.haskell.org/D1303
      
      	modified:   configure.ac
      a3c78abc
    • Tamar Christina's avatar
      Fix broken validation Build 6564 and accepting a few other test results · c4d7df04
      Tamar Christina authored
      Test Plan: ./validate
      
      Reviewers: thomie, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1304
      c4d7df04
    • Tamar Christina's avatar
      Prevent GHC from silently dying when preprocessor is not found · b6f76b9a
      Tamar Christina authored
      The Windows preprocessor code calls `runInteractiveProcess` but does
      not check if an exception is thrown.
      `runInteractiveProcess` calls `CreateProcess` which when given a format
      the system loader does not know about
      will throw an exception. This is what makes #9399 fail.
      
      Ultimately we should not use any `CreateProcess` based calls but
      instead `ShellExecuteEx` as  this would allow
      us to run applications that the shell knows about instead of just the
      loader. More details on #365.
      
      This patch removes `PhaseFailed` and throws `ProgramError` instead.
      `PhaseFailed` was largely unneeded since it never gave
      very useful information aside from the `errorcode` which was almost
      always `1`. `IOErrors` have also been eliminated and `GhcExceptions`
      thrown in their place wherever possible.
      
      Updates haddock submodule.
      
      Test Plan:
      `./validate` to make sure anything didn't break and
      `make TESTS="T365"` to test that an error is now properly thrown
      
      Reviewers: austin, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1256
      
      GHC Trac Issues: #365
      b6f76b9a
    • Ben Gamari's avatar
      docs: Fix ghc_config.py.in · 93e21b96
      Ben Gamari authored
      93e21b96
    • Ben Gamari's avatar
      Move user's guide to ReStructuredText · 4fd6207e
      Ben Gamari authored
      4fd6207e
  8. 02 Oct, 2015 5 commits
    • Edward Z. Yang's avatar
      Don't use old linkable for hs-boot files. · 9ed700bb
      Edward Z. Yang authored
      We should only use the old linkable when the really is nothing
      to be done.  In the case of hs-boot, there should just not be
      a linkable.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1301
      9ed700bb
    • Andreas Schwab's avatar
      Fix signature of atomic builtins · e3d2bab8
      Andreas Schwab authored
      This patch is due to Andreas Schwab.
      
      This fixes #10926, which reports (on AArch64) errors of the form,
      
      ```
      /tmp/ghc1492_0/ghc_1.hc:2844:25: warning: passing argument 1 of
      'hs_atomic_xor64' makes pointer from integer without a cast
      [-Wint-conversion]
           _c1Ho = hs_atomic_xor64((*Sp) + (((Sp[1]) << 0x3UL) + 0x10UL), Sp[2]);
                                   ^
      
      In file included from
      /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/Stg.h:273:0: 0,
                       from /tmp/ghc1492_0/ghc_1.hc:3:
      
      /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/stg/Prim.h:41:11:
           note: expected 'volatile StgWord64 *
                 {aka volatile long unsigned int *}'
                 but argument is of type 'long unsigned int'
           StgWord64 hs_atomic_xor64(volatile StgWord64 *x, StgWord64 val);
                     ^
      ```
      
      Test Plan: Validate
      
      Reviewers: austin, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1300
      
      GHC Trac Issues: #10926
      e3d2bab8
    • Ben Gamari's avatar
      Move CallStack back to base · 74424346
      Ben Gamari authored
      CallStack requires tuples, instances of which are defined in GHC.Tuple.
      Unfortunately the change made in D757 to the `Typeable` deriving
      mechanism means that `GHC.Tuple` must import `GHC.Types` for types
      necessary to generate type representations.  This results in a cycle.
      
      Test Plan: Validate
      
      Reviewers: gridaphobe, austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1298
      74424346
    • Ben Gamari's avatar
      LLVM: Factor out accumulation of LLVM statements and variables · 95394085
      Ben Gamari authored
      The LLVM code generator currently has a rather large amount of
      boilerplate devoted to piping around and building up various AST
      elements. This is rather unfortunate for a language which prides itself
      on ease of abstraction and detracts from readability.
      
      Here I continue a refactoring that I originally suggested in D991, using
      `WriterT` to factor out this pattern. `WriterT` is in general a bit
      problematic from an evaluation perspective, but the expressions here are
      small enough that it should be a problem in practice.
      
      Test Plan: Validate
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1286
      95394085
    • Ben Gamari's avatar
      LLVM: Implement atomic operations in terms of LLVM primitives · bd41eb2a
      Ben Gamari authored
      This fixes Trac #7883.
      
      This adds proper support for,
        * `MO_AtomicRMW`
        * `MO_AtomicWrite`
        * `MO_CmpXChg`
      
      Test Plan: Validate
      
      Reviewers: rrnewton, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1282
      
      GHC Trac Issues: #7883
      bd41eb2a