Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

These are needed by the testsuite and consequently must be shipped in
the testsuite tarball to ensure that we can test binary distributions.

See #13897.

Test Plan: Validate

Reviewers: austin

Subscribers: snowleopard, rwbarton, thomie

GHC Trac Issues: #13897

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

Summary:
The llvm-targets file records `mattr` values, and
while interrogating `clang` for the target, we might
stumble upon `+soft-float-abi`, however ghc does not support
full soft-float, and as such passing `+soft-float` to `llc`
will result in segfaults for any function passing float
registers F1, ... in the ARM Instruction Selection Pass.

Reviewers: bgamari, austin

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Summary:
Our usual GHC_CONVERT_OS macro, will turn any andoird* into android.
This however drops the essential androideabi part. As such for the
GHC_LLVM_TARGET we only convert the VENDOR, not the OS.

Reviewers: bgamari, austin, hvr

Reviewed By: bgamari

Subscribers: rwbarton, thomie, erikd

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

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

Exception handling on Windows is unfortunately a bit complicated.
But essentially the VEH Handlers we currently have are running too
early.

This was a problem as it ran so early it also swallowed C++ exceptions
and other software exceptions which the system could have very well
recovered from.

So instead we use a sequence of chains to for the exception handlers to
run as late as possible. You really can't get any later than this.

Please read the comment in the patch for more details.

I'm also providing a switch to allow people to turn off the exception
handling entirely. In case it does present a problem with their code.

(Reverted and recommitted to fix authorship information)

Test Plan: ./validate

Reviewers: austin, hvr, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13911, #12110

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

Reverting to fix authorship of commit.

This reverts commit 1825cbdb.

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: Validate, add tests

Reviewers: simonmar, austin, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie

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

Fixes #13929.

Niklas Hambüchen authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: bgamari, austin, hvr

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Exception handling on Windows is unfortunately a bit complicated.
But essentially the VEH Handlers we currently have are running too
early.

This was a problem as it ran so early it also swallowed C++ exceptions
and other software exceptions which the system could have very well
recovered from.

So instead we use a sequence of chains to for the exception handlers to
run as late as possible. You really can't get any later than this.

Please read the comment in the patch for more details.

I'm also providing a switch to allow people to turn off the exception
handling entirely. In case it does present a problem with their code.

Test Plan: ./validate

Reviewers: austin, hvr, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13911, #12110

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: angerman, austin, erikd, simonmar

Subscribers: rwbarton, thomie

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: austin

Subscribers: rwbarton, thomie

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

Summary:
It seems the call that caused issues with the gcc wrapper before
was needed for the ghci wrapper in order for the child process
to be the one handling console events.

This code slightly refactors the wrappers to make sure only ghci
calls FreeConsole and nothing else.

Test Plan: ./validate , open ghci.exe press ctrl+c

Reviewers: RyanGlScott, austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, erikd

GHC Trac Issues: #14150

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14272

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

This should result in zero. Failing to realize this caused us to try
to constant-fold via the normal path, resulting in #14272.

Test Plan: Validate with coming tests

Reviewers: austin, simonpj

Subscribers: simonpj, rwbarton, thomie, hvr

GHC Trac Issues: #14272

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Trac #14192 points out that currently GHC's two-step allocator results
in extremely large coredumps. It seems like WebKit may have encountered
similar issues and their apparent solution uses madvise(MADV_DONTNEED)
while reserving address space to inform the kernel that the address
space we just requested needs no backing. Perhaps this is used by the
core dump logic to trim out uncommitted pages.

Test Plan: Validate, try core-dumping a compiled executable

Reviewers: austin, erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie

GHC Trac Issues: #14192, #14193

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

The overloading of "monadic" definitely deserved some explanation.

[skip ci]

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

The simplifier can simplify this without any trouble. Moreover, the
unboxed tuples cause bootstrapping issues due #14123.

I also went ahead and inlined a few definitions into the Monad instance.

Test Plan: Validate

Reviewers: austin, simonmar

Subscribers: rwbarton, thomie

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

In doing something else (Trac #14218) I tripped over the
definition of "naturally coherent" classes.  This patch

- Cocuments properly what that means

- Removes Typeable from the list, because now we know what
  it meams, Typeable clearly doesn't belong.

No regressions.

(Actually the term "naturally coherent" seems a bit off.
More like "invertible" or something.  But I left it.)

Spurious output pertaining to dynamic linking causes it to fail. See #14276.

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

For reasons that I don't entirely understand we didn't previously detect
`strip` using autoconf. This naturally broke during cross-compilation.
How did this ever work? I have no idea.

Test Plan: Try cross-compiling

Reviewers: austin, hvr, angerman

Subscribers: rwbarton, thomie, erikd

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Previously we didn't specify the prog-not-found value passed to
AC_CHECK_TOOLS.  Reported by @snowleopard in
https://github.com/snowleopard/hadrian/issues/415.

Test Plan: validate

Reviewers: austin, hvr

Subscribers: rwbarton, thomie, snowleopard, erikd

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: austin, erikd, simonmar

Subscribers: NicolasT, rwbarton, thomie

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

As mentioned in #14275, GHC will otherwise decide to produce unfoldings
for this rather large binding, making recompilation more expensive than
necessary. Since inlining is almost certainly not fruitful mark it as
NOINLINE.

[skip ci]

Test Plan: Validate

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14275

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Just fix a few inconsistencies that I encountered.

[skip ci]

Reviewers: austin, hvr, goldfire

Subscribers: rwbarton, thomie

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

enolan authored 7 years ago and Ben Gamari committed 7 years ago

Prior to this commit, worker OS thread were renamed to "ghc_worker" when
spawned. This was annoying when reading debugging messages that print
the process name because it doesn't tell you *which* Haskell program is
generating the message.

This commit changes it to "original_process_name:w", truncating the
original name to fit in the kernel buffer if neccesary.

Test Plan: ./validate

Reviewers: austin, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: Phyx, rwbarton, thomie

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: Read it

Reviewers: dfeuer, goldfire, austin, hvr

Reviewed By: dfeuer

Subscribers: rwbarton, thomie

GHC Trac Issues: #14199

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

Moritz Angermann authored 7 years ago and Tamar Christina committed 7 years ago

Summary:
This fixes hadrian#420 (https://github.com/snowleopard/hadrian/issues/420)

specifically the "Unknown OS mingw64".

Reviewers: austin, hvr, bgamari, Phyx

Reviewed By: Phyx

Subscribers: rwbarton, thomie, erikd

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

Summary:
Ar was being checked twice prior to D3883 where I removed one of the checks
because the converted path was being overridden after the check because of
the second check for Ar. However the one in configure.ac was a target check
so I'm changing the path check to a target check now.

Test Plan: ./configure

Reviewers: angerman, austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, erikd

GHC Trac Issues: #14274

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

Summary:
Something seems to be changing stderr into binary mode,
so when the `traceIO` is called, the C code that ultimately
calls `vfprintf` is using a binary mode handle.

This causes newlines not to be encoded properly.

The patch ensures we're in text mode when writing the debug
messages (% interleaving as it's not thread safe at all) and restores
the previous mode when done.

I'm slightly concerned about the performance implications of writing
large dumps out in text mode, but I think the current behavior is not
intended as I cannot see any of the printing code setting the mode of
the std handles.

Test Plan: ./validate

Reviewers: austin, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #14188

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

Summary:
Now that `MonadIO` is a superclass of `Quasi`, it's a good
time to bump the `template-haskell` version so that libraries can
accommodate the change using CPP.

Test Plan: ./validate

Reviewers: bgamari, austin

Subscribers: rwbarton, thomie

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

Summary:
Up until now, the knowledge of how GHC chooses which
`COMPLETE` set to use in the presence of multiple applicable
`COMPLETE` sets for a single data type constructor was only
documented in the GHC wiki. But this really should be advertised to
anyone who uses `COMPLETE` pragmas heavily, so per SPJ's advice in
https://ghc.haskell.org/trac/ghc/ticket/14253#comment:10, this adds
this wisdom to the GHC users' guide.

Test Plan: Read it

Reviewers: austin, bgamari

Subscribers: mpickering, rwbarton, thomie

GHC Trac Issues: #14253

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

Trac #14218 showed that we were not solving implicit-parameter
constraints correctly.  In particular,

- A tuple constraint could "hide" an implicit-parameter wanted
  constraint, and that in turn could that we solved it from the
  wrong implicit-parameter binding.

- As a special case the HasCallStack constraint (which is just
  short for (IP "callStack" CallStack), was getting mis-solved.

The big change is to arrange that, in TcSMonad.findDict when looking
for a dictionary, either when looking for a matching inert or solved
dictionary, we fail for

  - Tuples that are hiding implicit parameters
    See Note [Tuples hiding implicit parameters]

  - HasCallStack constraints where we have not yet pushed
    on the call-site info
    See Note [Solving CallStack constraints]

I also did a little refactoring

* Move naturallyCoherentClass from Class to TcInteract, its sole
  use site.  Class.hs seems like the wrong place.  (And I also
  do not understand the reason that we need the eq/Coercible/
  Typable stuff in this predicate, but I'll tackle that separately.)

* Move the code that pushes call-site info onto a call stack
  from the "interact" part to the "canonicalise" part of the solver.

This patch does two things:

* When reporting a hole, we now include its kind if the
  kind is not just '*'.  This addresses Trac #14265

* When reporting things like "'a' is a rigid type varaible
  bound by ...", this patch arranges to group the type variables
  together, so we don't repeat the "bound by..." stuff endlessly

This just does wrapping on very long lists

For reasons explained in TcHsType
Note [Extra-constraint holes in partial type signatures],
if we had
  f :: (_) => blahs
and the '_' was filled in by more than a 62-tuple of contraints,
GHC crashed.

The same Note explains the hacky solution I have adopted to
evade this.  Maybe there is some better way, but I couldn't
see one that didn't involve a great deal of work. And the problem
is a very narrow one!  If the hack bites us we'll need to think
again.

AsmTempLabel is really a label that describes
label in assembly output (or equivalent like LLVM IR).

Unregisterised build does not handle it correctly.

This change does not fix UNREG build failure in
Ticket #14264 but reverts back to panic:
    pprCLbl AsmTempLabel

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>