GitLab

Edward Z. Yang authored Oct 02, 2015 and Ben Gamari committed Oct 02, 2015

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: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1301

Andreas Schwab authored Oct 02, 2015 and Ben Gamari committed Oct 02, 2015

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

Ben Gamari authored Oct 02, 2015 and Ben Gamari committed Oct 02, 2015

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

Ben Gamari authored Oct 02, 2015 and Ben Gamari committed Oct 02, 2015

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

Ben Gamari authored Oct 02, 2015 and Ben Gamari committed Oct 02, 2015

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

Peter Trommler authored Oct 02, 2015 and Ben Gamari committed Oct 02, 2015

Implement access to spill slots at offsets larger than 16 bits.
Also allocation and deallocation of spill slots was restricted to
16 bit offsets. Now 32 bit offsets are supported on all PowerPC
platforms.

The implementation of 32 bit offsets requires more than one instruction
but the native code generator wants one instruction. So we implement
pseudo-instructions that are pretty printed into multiple assembly
instructions.

With pseudo-instructions for spill slot allocation and deallocation
we can also implement handling of the back chain pointer according
to the ELF ABIs.

Test Plan: validate (especially on powerpc (32 bit))

Reviewers: bgamari, austin, erikd

Reviewed By: erikd

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1296

GHC Trac Issues: #7830

Matthias Fischmann authored Oct 02, 2015 and Ben Gamari committed Oct 02, 2015

Reviewers: bgamari, hvr, austin

Reviewed By: bgamari, hvr, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1289

Ben Gamari authored Oct 02, 2015 and Ben Gamari committed Oct 02, 2015

Here we fix a few mis-optimizations that could occur in code with
floating point comparisons with -0.0. These issues arose from our
insistence on rewriting equalities into case analyses and the
simplifier's ignorance of floating-point semantics.

For instance, in Trac #10215 (and the similar issue Trac #9238) we
turned `ds == 0.0` into a case analysis,

```
case ds of
    __DEFAULT -> ...
    0.0 -> ...
```

Where the second alternative matches where `ds` is +0.0 and *also* -0.0.
However, the simplifier doesn't realize this and will introduce a local
inlining of `ds = -- +0.0` as it believes this is the only
value that matches this pattern.

Instead of teaching the simplifier about floating-point semantics
we simply prohibit case analysis on floating-point scrutinees and keep
this logic in the comparison primops, where it belongs.

We do several things here,

 - Add test cases from relevant tickets
 - Clean up a bit of documentation
 - Desugar literal matches against floats into applications of the
   appropriate equality primitive instead of case analysis
 - Add a CoreLint to ensure we don't pattern match on floats in Core

Test Plan: validate with included testcases

Reviewers: goldfire, simonpj, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1061

GHC Trac Issues: #10215, #9238

reverting my bogus commit there.

to contain these commits:
   commit 8bffe3cb01ce404ab493de2b4316f2c1c4a9bda9
   Author: Joachim Breitner <mail@joachim-breitner.de>
   Date:   Fri Oct 2 10:09:17 2015 +0200

       Expected output of mandel when run under valgrind

       probably due to rounding/floating point precision numbers. It looks
       broken, but so does the existing file spectral/mandel/mandel.stdout-mingw.

   commit f9a577973edf6976e4c0703bf2afac900d7b6fd8
   Author: Gabor Greif <ggreif@gmail.com>
   Date:   Fri Jul 31 00:43:38 2015 +0200

       Typos in comments

   commit 20ae9113ad31eca426883544f597a3cae9b60d94
   Author: Simon Peyton Jones <simonpj@microsoft.com>
   Date:   Fri Apr 24 15:10:02 2015 +0100

       Add exact-real-arithmetic benchmark from David Lester

This implements phase 1 of the semigroup-as-monoid-superclass
proposal (https://ghc.haskell.org/wiki/Proposal/SemigroupMonoid).

The modules were migrated from the `semigroups-0.17` release mostly
as-is, except for dropping several trivial `{-# INLINE #-}`s,
removing CPP usage, and instances for types & classes provided
outside of `base` (e.g. `containers`, `deepseq`, `hashable`, `tagged`,
`bytestring`, `text`)

Differential Revision: https://phabricator.haskell.org/D1284

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

The Haskell 2010 report chapter 2.6 (Characters and String Literals)
says:

  "Numeric escapes such as \137 are used to designate the character with
  decimal representation 137; octal (e.g. \o137) and hexadecimal (e.g.
  \x37) representations are also allowed."

Commit 1c0b5fdc added syntax for writing
character literals using binary notation (e.g. '\b100100'). But this
code can never be reached, because '\b' already represents "backspace".

Turn on -fwarn-overlapping-patterns to catch such bugs in the future.

Reviewed by: hvr

Differential Revision: https://phabricator.haskell.org/D1291

The function is very small and the compiler should be at liberty to
inline it. But it is recursive, so it did not do it before. By applying
the usual transformation with a local recursive function, GHC can now
inline it, producing the loop that one would expect.

Ömer Sinan Ağacan authored Sep 26, 2015 and Ben Gamari committed Sep 26, 2015

As reported in Trac #10891, Template Haskell's `reify` was not
generating Decls for associated types. This patch fixes that.

Note that even though `reifyTyCon` function used in this patch returns
some type instances, I'm ignoring that.

Here's an example of how associated types are encoded with this patch:

(Simplified representation)

    class C a where
      type F a :: *

    -->

    OpenTypeFamilyD "F" ["a"]

With default type instances:

    class C a where
      type F a :: *
      type F a = a

    -->

    OpenTypeFamilyD "F" ["a"]
    TySynInstD "F" (TySynEqn [VarT "a"] "a")

Test Plan:
This patch was already reviewed and even merged. The patch is later
reverted because apparently it broke the build some time between the
validation of this patch and merge. Creating this new ticket to fix the
validation.

Reviewers: goldfire, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1277

GHC Trac Issues: #10891

and not the system locale, which might be something else. This fixes
bug #10907. A test is added, but less useful than it could be until
task #10909 is done.

Differential Revision: D1274

Ben Gamari authored Sep 25, 2015 and Ben Gamari committed Sep 25, 2015

This is supposed to be encoded with ULEB128 which the previous
implementation would only guarranty with short lengths. This likely
holds in nearly all cases, but I'd really rather not take changes.

I fix this using the `.uleb128` directive. I'm not certain that this is
portable across assemblers but it makes this quite straightforward and
at the moment I value correctness over portability.

Test Plan: Compare implementation to DWARF spec

Reviewers: scpmw, austin

Reviewed By: austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1220

Ben Gamari authored Sep 25, 2015 and Ben Gamari committed Sep 25, 2015

Reviewers: austin

Reviewed By: austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1221

To quote Simon Marlow,

    We don't expect users to ever write code that uses mkWeak# or
    finalizeWeak#, we have safe interfaces to these. Let's document the type
    unsafety and fix the problem with () without introducing any overhead.

Updates stm submodule.

Summary:
DeriveGeneric generates some data types (for data type constructors and for
selectors of those constructors) and instances for those types. This patch
changes name generation for these new types to make it working with data types
with same names imported from different modules and with data types with same
names imported from same modules(using module imports).

Bonus content:

- Some refactoring in `TcGenGenerics.metaTyConsToDerivStuff` to remove some
  redundant partial function applications and to remove a duplicated function.
- Remove some unused names from `OccName`. (those were used for an old
  implementation of `DeriveGeneric`)

Reviewers: kosmikus, simonpj, dreixel, ezyang, bgamari, austin

Reviewed By: bgamari, austin

Subscribers: ezyang, thomie

Differential Revision: https://phabricator.haskell.org/D1081

GHC Trac Issues: #10487

Summary: See Note [MallocPtr finalizers]

Test Plan: validate; new test T10904

Reviewers: ezyang, bgamari, austin, hvr, rwbarton

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1275

This caused the build to fail, due to some type checking errors. Whoops.

This reverts commit 5c115236.

As reported in Trac #10891, Template Haskell's `reify` was not generating Decls
for associated types. This patch fixes that.

Note that even though `reifyTyCon` function used in this patch returns some
type instances, I'm ignoring that.

Here's an example of how associated types are encoded with this patch:

(Simplified representation)

    class C a where
      type F a :: *

    -->

    OpenTypeFamilyD "F" ["a"]

With default type instances:

    class C a where
      type F a :: *
      type F a = a

    -->

    OpenTypeFamilyD "F" ["a"]
    TySynInstD "F" (TySynEqn [VarT "a"] "a")

Reviewed By: goldfire

Differential Revision: https://phabricator.haskell.org/D1254

GHC Trac Issues: #10891

Previously it was only available from GHC.Conc, but it makes sense for it to be
available from a more official place where people might find it.

While I was here, I improved the docs a little.

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D1272

This should (1) fix the ./validate build, which I accidentally broke in D1168,
and (2) update the Cabal submodule so that it recognizes `DeriveLift` as a GHC
extension.

Reviewed By: adamse, austin

Differential Revision: https://phabricator.haskell.org/D1269

GHC Trac Issues: #1830

This adds a constant-folding rule for `Integer`'s implementation of `bit` and
fixes the `T8832` testcase. Fixes #8832.

Reviewed By: simonpj, austin

Differential Revision: https://phabricator.haskell.org/D1255

GHC Trac Issues: #8832

Summary:
This allows the code generator to give hints to later code generation
steps about which branch is most likely to be taken.  Right now it
is only taken into account in one place: a special case in
CmmContFlowOpt that swapped branches over to maximise the chance of
fallthrough, which is now disabled when there is a likelihood setting.

Test Plan: validate

Reviewers: austin, simonpj, bgamari, ezyang, tibbe

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1273

Previously CallStacks would be built using String, which would pull in
GHC.Base while compiling GHC.Err. Use [Char] instead.

Previously the types needlessly used (), which is defined ghc-prim,
leading to unfortunate import cycles. See #10867 for details.

Updates stm submodule.

A few tests had the same name which is a big no-no, so I reorganized them a
little. The naming is somewhat haphazard, though...
Signed-off-by: Austin Seipp <austin@well-typed.com>

Clang's CPP implementation seems to barf otherwise

Summary:
This implements -XDeriveLift, which allows for automatic derivation
of the Lift class from template-haskell. The implementation is based
off of Ian Lynagh's th-lift library
(http://hackage.haskell.org/package/th-lift).

Test Plan: ./validate

Reviewers: hvr, simonpj, bgamari, goldfire, austin

Reviewed By: goldfire, austin

Subscribers: osa1, thomie

Differential Revision: https://phabricator.haskell.org/D1168

GHC Trac Issues: #1830

The names of auxiliary bindings end up in the interface file, and since uniques
are nondeterministic, we end up with nondeterministic interface files.

This uses the package and module name in the generated name, so I believe it
should avoid problems from #7947 and be deterministic as well.

The generated names look like this now:

  `$cLrlbmVwI3gpI8G2E6Hg3mO`

and with `-ppr-debug`:

  `$c$aeson_70dylHtv1FFGeai1IoxcQr$Data.Aeson.Types.Internal$String`.

Reviewed By: simonmar, austin, ezyang

Differential Revision: https://phabricator.haskell.org/D1133

GHC Trac Issues: #4012