Tamar Christina authored 9 years ago and Ben Gamari committed 9 years ago

Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc
to pass -L to all components by using -B instead. These two fix
shortnames linking on windows.

re-enabled tests: ghcilink003, ghcilink006 and T3333
Added two tests: load_short_name and enabled T1407 on windows.

Reviewed By: thomie, bgamari

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

GHC Trac Issues: #9878, #1407, #1883, #5289

Matthew Pickering authored 9 years ago and Ben Gamari committed 9 years ago

For example

```
pattern head `Cons` tail = head : tail
```

Reviewed By: goldfire, austin

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

GHC Trac Issues: #10747

Thomas Miedema authored 9 years ago and Ben Gamari committed 9 years ago

Among doing other things, Phab:D201 (bc2289e1)
tried to improve the error messages thrown by the parser. For example a missing
else clause now prints "parse error in if statement: else clause empty" instead
of "parse error (possibly incorrect indentation or mismatched brackets)".

Some error messages got much worse however (see tests), and the result seems to
be a net negative. Although not entirely satisfactory, this commits therefore
reverts those parser changes.

Reviewed By: austin

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

GHC Trac Issues: #10498

Erik de Castro Lopo authored 9 years ago and Ben Gamari committed 9 years ago

Backported from:

    commit 4bd58c17
    Author: Erik de Castro Lopo <erikd@mega-nerd.com>
    Date:   Sun Sep 13 18:57:40 2015 +1000

    PPC: Fix right shift by 32 bits #10870

The patch in HEAD didn't apply cleanly because of the powerpc64el
work that has been done in HEAD.

Erik de Castro Lopo authored 9 years ago and Ben Gamari committed 9 years ago

Arm has two instruction sets, Arm and Thumb, and an execution mode for each.
Executing Arm code in Thumb mode or vice-versa will likely result in an
Illegal instruction exception.

Furthermore, Haskell code compiled via LLVM was generating Arm instructions
while C code compiled via GCC was generating Thumb code by default. When
these two object code types were being linked by the system linker, all was
fine, because the system linker knows how to jump and call from one
instruction set to the other.

The first problem was with GHCi's object code loader which did not know
about Thumb vs Arm. When loading an object file `StgCRun` would jump
into the loaded object which could change the mode causing a crash after
it returned. This was fixed by forcing all C code to generate Arm
instructions by passing `-marm` to GCC.

The second problem was the `mkJumpToAddr` function which was generating
Thumb instructions. Changing that to generate Arm instructions instead
results in a working GHCi on Arm.

Test Plan: validate on x86_64 and arm

Reviewers: bgamari, austin, hvr

Subscribers: thomie

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

GHC Trac Issues: #10375

A missing 'closeOverKinds' triggered Trac #10934.
Happily the fix is simple.

Merge to 7.10.3

This makes two real changes:
 - Equalities like (a ~R [a]) really *are* insoluble. Previously,
   GHC refused to give up when an occurs check bit on a representational
   equality. But for datatypes, it really should bail.

 - Now, GHC will sometimes report an occurs check error (in cases above)
   for representational equalities. Previously, it never did.

This "fixes" #10715, where by "fix", I mean clarifies the error message.
It's unclear how to do more to fix that ticket.

Test cases: typecheck/should_fail/T10715{,b}

This change means that the intricate reasoning in TcErrors
around getting messages just right for nominal equalities
is skipped for representational equalities.

HERMIT users depend on RULES to specify equational properties. 6.10.2
performed both inlining and simplification in both sides of the rules,
meaning they can't really be used for this. This breaks most HERMIT use
cases.  A separate commit already disabled this for the LHS of rules.
This does so for the RHS.

See Trac #10829 for nofib results.

Reviewed By: austin, bgamari, simonpj

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

GHC Trac Issues: #10829

Tamar Christina authored 10 years ago and Ben Gamari committed 9 years ago

This patch does a few things

- Moved GHC x86 to MinGW-w64 (Using Awson's patch)
- Moves Both GHCs to MSYS2 toolchains
- Completely removes the dependencies on the git tarball repo
  - Downloads only the required tarball for the architecture for
    which we are building
  - Downloads the perl tarball is missing as well
  - Fixed a few bugs in the linker to fix tests on Windows

The links currently point to repo.msys2.org and GitHub, it might be
more desirable to mirror them on
http://downloads.haskell.org/~ghc/mingw/ as with the previous patch
attempt.

For more details on what the MSYS2 packages I include see #10726
(Awson's comment). but it should contain all we need
and no python or fortran, which makes the uncompressed tar a 1-2
hundreds mb smaller.

The `GCC 5.2.0` in the package supports `libgcc` as a shared library,
this is a problem since
when compiling with -shared the produced dll now has a dependency on
`libgcc_s_sjlj-1.dll`.
To solve this the flag `-static-libgcc` is now being used for all GCC
calls on windows.

Test Plan:
./validate was ran both on x86 and x86_64 windows and compared against
the baseline.

A few test were failing due to Ld no longer being noisy. These were
updated.

The changes to the configure script *should* be validated by the build
bots for the other platforms before landing

Reviewers: simonmar, awson, bgamari, austin, thomie

Reviewed By: thomie

Subscribers: #ghc_windows_task_force, thomie, awson

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

GHC Trac Issues: #10726, #9014, #9218, #10435

Apparently some Clang 3.6 expects these to be sorted.

Patch due to Peter Wortmann.

Fixes #10687.

This was likely due to an incorrectly merged conflict during
cherry-picking.

Erik de Castro Lopo authored 9 years ago and Ben Gamari committed 9 years ago

Back port of Peter Trommler's patch from master (19dae027cb) to the
7.10 branch. Peter's commit does not apply to the 7.10 branch because
PowerPC64 was added to master after the 7.10 branch was started.

Comments from the original commit:
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.

This fixes #10810 by cleaning up pretty-printing of constructor
declarations. This change also removes a (in my opinion) deeply
bogus orphan instance OutputableBndr [Located name], making
HsDecls now a non-orphan module. Yay all around.

Test case: th/T10810

Ben Gamari authored 9 years ago and Ben Gamari committed 9 years ago

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

This fixes the GHC side of trac #10568. So `cabal install
--ghc-options="-framework GLUT" GLUT` creates a correctly linked
GLUT.dylib. We still need to explictly pass `--ghc-options="-framework
GLUT"` because the Cabal side #10568 is not fixed.

Update: the Cabal side of #10568 is fixed by
[Cabal#2747](https://github.com/haskell/cabal/pull/2747)

Test Plan: validate

Reviewers: austin, rwbarton, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

GHC Trac Issues: #10568

Test Plan: validate

Reviewers: goldfire, austin, simonpj, bgamari

Reviewed By: bgamari

Subscribers: simonpj, rwbarton, thomie, bgamari

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

GHC Trac Issues: #10596

spinda authored 10 years ago and Ben Gamari committed 9 years ago

With -dynamic-too, .dyn_o files were not being generated for .hsig
files.  Normally, this is handled in the pipeline; however, the branch
for .hsig files called compileEmptyStub directly instead of going
through runPipeline.  When compiling a Cabal package that included .hsig
files, this triggered a linker error later on, as it expected a .dyn_o
file to have been generated for each .hsig.

The fix is to use runPipeline for .hsig files, just as with .hs files.
Alternately, one could duplicate the logic for handling -dynamic-too in
the .hsig branch, but simply calling runPipeline ends up being much
cleaner.

Test Plan: validate

Reviewers: austin, ezyang, bgamari, thomie

Reviewed By: ezyang, thomie

Subscribers: thomie

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

GHC Trac Issues: #10660

Test Plan: Validate.

Reviewers: austin, tibbe, bgamari

Reviewed By: tibbe, bgamari

Subscribers: thomie

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

GHC Trac Issues: #10413

When doing the apartness/flattening thing, we really only need to
eliminate non-generative tycons, not *all* families. (Data families
are indeed generative!)

thomasw authored 10 years ago and Ben Gamari committed 9 years ago

When a constructor was mistakenly imported directly instead of as a
constructor of a data type, a hint will be shown on how to correctly
import
it. Just like the constructor, the data type should be surrounded in
parentheses if it is an operator (TypeOperator in this case).

Instead of:

    error:
        In module ‘Data.Type.Equality’:
          ‘Refl’ is a data constructor of ‘:~:’
        To import it use
          ‘import’ Data.Type.Equality( :~:( Refl ) )
        or
          ‘import’ Data.Type.Equality( :~:(..) )

Print:

    error:
        In module ‘Data.Type.Equality’:
          ‘Refl’ is a data constructor of ‘(:~:)’
        To import it use
          ‘import’ Data.Type.Equality( (:~:)( Refl ) )
        or
          ‘import’ Data.Type.Equality( (:~:)(..) )

Test Plan: pass new test

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, thomie

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

GHC Trac Issues: #10668

See Note [Unbound template type variables] in Rules.hs
This fixes Trac #10689.

The problem was a rule LHS that mentioned a type variable
in a phantom argument to a type synonym.  Then matching the
LHS didn't bind the type variable, and the rule matcher
complained.

This patch fixes the problem, as described by the Note.

I also went back to not-cloning the template varaibles during
rule matching.  I'm convinced that it's not necessary now
(if it ever was), and cloning makes the fix for #10689 much more
fiddly.

This is the right thing to do anyway, and fixes Trac #10528

This fixes an ASSERT failure in TcBinds.  The problem was that we
were generating NoGen plan for a function with a partial type signature,
and that led to confusion and lost invariants.

See Note [Partial type signatures and generalisation] in TcBinds

kanetw authored 9 years ago and Ben Gamari committed 9 years ago

For now, this fails compliation immediately with an error. If desired, this
can be a warning that annotations in Safe Haskell are ignored.

Signed-off-by: David Kraeutmann <kane@kane.cx>

Reviewed By: goldfire, austin

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

GHC Trac Issues: #10826

Michael Snoyman authored 9 years ago and Ben Gamari committed 9 years ago

On Windows, we're constrained to 32k bytes total for command line
arguments.  When building large projects, this limit can be exceeded.
This patch changes GHC to always use response files for linker
arguments, a feature first used by Microsoft compilers and added to GCC
(over a decade ago).

Alternatives here include:

* Only use this method on Windows systems
* Check the length of the command line arguments and use that to decide
  whether to use this method

I did not pursue either of these, as I believe it would make the patch
more likely to break in less tested situations.

Test Plan:
Confirm that linking still works in general. Ideally: compile a very
large project on Windows with this patch. (I am attempting to do that
myself now, but having trouble getting the Windows build tool chain up
and running.)

Reviewers: goldfire, hvr, rwbarton, austin, thomie, bgamari, Phyx

Reviewed By: thomie, bgamari, Phyx

Subscribers: erikd, awson, #ghc_windows_task_force, thomie

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

GHC Trac Issues: #8596, #10777

Michael Snoyman authored 9 years ago and Ben Gamari committed 9 years ago

This avoids the compiler from crashing when, for example, a warning
contains a non-Latin identifier and the LANG variable is set to C.
Fixes #6037.

Test Plan:
Create a Haskell source file containing an identifier with non-Latin
characters and no type signature. Compile with `LANG=C ghc -Wall
foo.hs`, and it should fail. With this patch, it will succeed.

Reviewers: austin, rwbarton, bgamari

Subscribers: thomie

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

GHC Trac Issues: #6037, #10762

Michael Snoyman authored 9 years ago and Ben Gamari committed 9 years ago

When the Windows codepage or *nix LANG variable is something besides
UTF-8, dumping to file can cause GHC to exit currently. This changes the
output encoding for files to match the defined input encoding for
Haskell source code (UTF-8), making it easier for users and build tools
to capture this output.

Test Plan:
Create a Haskell source file with non-Latin characters for identifier
names and
compile with:

LANG=C ghc -ddump-to-file -ddump-hi filename.hs -fforce-recomp

Without this patch, it will fail. With this patch, it succeeds

Reviewers: austin, rwbarton, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #10762

Ben Gamari authored 10 years ago and Ben Gamari committed 9 years ago

While we have always had makeDynFlagsConsistent to enforce a variety of
consistency invariants on DynFlags, it hasn't been widely used.
GHC.Main, for instance, ignored it entirely. This leads to issues like
Trac #10549, where an OPTIONS_GHC pragma introduced an inconsistency,
leading to a perplexing crash later in compilation.

Here I add consistency checks in GHC.Main.set{Session,Program}DynFlags,
closing this hole.

Fixes #10549.

Test Plan: Validate with T10549

Reviewers: austin

Subscribers: thomie

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

GHC Trac Issues: #10549

Cherry-Picked-From: eca9a1a1

Dang, roles are annoying.

Test case: typecheck/should_compile/T10489

Cherry-Picked-From: 61b96a86
Conflicts:
	testsuite/tests/typecheck/should_compile/all.T

This was likely due to an incorrectly merged conflict during
cherry-picking.

HERMIT users depend on RULES to specify equational properties. 6.10.2
performed both inlining and simplification in both sides of the rules,
meaning they can't really be used for this. This breaks most HERMIT use
cases.  A separate commit already disabled this for the LHS of rules.
This does so for the RHS.

See Trac #10829 for nofib results.

Reviewed By: austin, bgamari, simonpj

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

GHC Trac Issues: #10829

Tamar Christina authored 10 years ago and Ben Gamari committed 9 years ago

This patch does a few things

- Moved GHC x86 to MinGW-w64 (Using Awson's patch)
- Moves Both GHCs to MSYS2 toolchains
- Completely removes the dependencies on the git tarball repo
  - Downloads only the required tarball for the architecture for
    which we are building
  - Downloads the perl tarball is missing as well
  - Fixed a few bugs in the linker to fix tests on Windows

The links currently point to repo.msys2.org and GitHub, it might be
more desirable to mirror them on
http://downloads.haskell.org/~ghc/mingw/ as with the previous patch
attempt.

For more details on what the MSYS2 packages I include see #10726
(Awson's comment). but it should contain all we need
and no python or fortran, which makes the uncompressed tar a 1-2
hundreds mb smaller.

The `GCC 5.2.0` in the package supports `libgcc` as a shared library,
this is a problem since
when compiling with -shared the produced dll now has a dependency on
`libgcc_s_sjlj-1.dll`.
To solve this the flag `-static-libgcc` is now being used for all GCC
calls on windows.

Test Plan:
./validate was ran both on x86 and x86_64 windows and compared against
the baseline.

A few test were failing due to Ld no longer being noisy. These were
updated.

The changes to the configure script *should* be validated by the build
bots for the other platforms before landing

Reviewers: simonmar, awson, bgamari, austin, thomie

Reviewed By: thomie

Subscribers: #ghc_windows_task_force, thomie, awson

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

GHC Trac Issues: #10726, #9014, #9218, #10435

Apparently some Clang 3.6 expects these to be sorted.

Patch due to Peter Wortmann.

Fixes #10687.

Erik de Castro Lopo authored 9 years ago and Ben Gamari committed 9 years ago

Back port of Peter Trommler's patch from master (19dae027cb) to the
7.10 branch. Peter's commit does not apply to the 7.10 branch because
PowerPC64 was added to master after the 7.10 branch was started.

Comments from the original commit:
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.

This fixes #10810 by cleaning up pretty-printing of constructor
declarations. This change also removes a (in my opinion) deeply
bogus orphan instance OutputableBndr [Located name], making
HsDecls now a non-orphan module. Yay all around.

Test case: th/T10810

Ben Gamari authored 9 years ago and Ben Gamari committed 9 years ago

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