Set RELEASE=NO

Signed-off-by: Austin Seipp <austin@well-typed.com>
Fix linked list manipulation code (buggy on consecutive deletion)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
(cherry picked from commit e3938f3adac0093b23694fd347774244ce121478)
--with-gcc overrides CC_STAGE0 when not cross-compiling (#8498)

(cherry picked from commit 6189c7674fc5c735db1a446d0b222369a3767369)
Don't perform permission checks for scripts named with -ghci-script (#6017)

The user explicitly requested this script on the command-line, so it's
unnecessary to require that the script is also owned by the user.
Also, it is currently impossible to make a GHCi wrapper that invokes a
custom script without first making a copy of the script to circumvent
the permissions check, which seems wrong.

(cherry picked from commit a6f2c852d49313fa8acea2deb3741ab86c6ef995)
Include EXTRA_LD_OPTS (amongst other things) when linking programs

One problem was that we weren't including $1_$2_DIST_LD_OPTS when
linking a program, which looks to be accidental: it was being defined
but not used anywhere.  This meant that setting $1_$2_EXTRA_LD_OPTS,
for example, had no effect.

This commit straightens out the handling of LD_OPTS to be consistent
with the way we handle CC_OPTS and HC_OPTS.

(cherry picked from commit 975e9cb8e7744a0750bb6c8763f628e05672643e)
Pass custom CC and LD opts to Cabal when configuring a package

Cabal compiles a program to check for the existence of foreign
libraries, so it needs to know our custom options, if any.

(cherry picked from commit e7f26cd3e7e9eb92e3eb3457730e635747b43050)
Include SRC_CC_OPTS and SRC_LD_OPTS when compiling ghc-cabal

(cherry picked from commit d011cdefca7aa66cbcf71c941f38a4e6dd4c5579)
Use LDFLAGS when compiling ghc-pwd

(cherry picked from commit 2aa78106ae8f3c9b71d7b85c2a8a5558c4c35fb4)
Remove debugging output

(cherry picked from commit 4c8edfd2c722504baaa6896d194fd3a8c3f9b652)
Include LD_OPTS when building the RTS shared libs

(cherry picked from commit ec3e949e29990c054850f621e14a9d77e3197aee)
Don't preprocess .s files

One important reason is that gcc 4.8.1 sometimes crashes:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436

Another reason is that preprocessing assembly files unnecessarily
slows down compilation.

(cherry picked from commit 396648eebaa1144d4d1f5326db716e8130f73732)
Fix #8641, creating directories when we have stubs.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
(cherry picked from commit c7498bbdaa74dadd976c75c4e303c2050aa78277)
Small issue with signatures in a TH splice (fixes Trac #8932)

(cherry picked from commit d8d798b1b33ab0593ed03f193360b8725ba2c2ba)

Conflicts:
	testsuite/tests/th/all.T
Be less untruthful about the prototypes of external functions

GHC's generated C code uses dummy prototypes for foreign imports.  At the
moment these all claim to be (void), i.e. functions of zero arguments.  On
most platforms this doesn't matter very much: calls to these functions put
the parameters in the usual places anyway, and (with the exception of
varargs) things just work.

However, the ELFv2 ABI on ppc64 optimises stack allocation
(http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01149.html): a call to a
function that has a prototype, is not varargs, and receives all parameters
in registers rather than on the stack does not require the caller to
allocate an argument save area.  The incorrect prototypes cause GCC to
believe that all functions declared this way can be called without an
argument save area, but if the callee has sufficiently many arguments then
it will expect that area to be present, and will thus corrupt the caller's
stack.  This happens in particular with calls to runInteractiveProcess in
libraries/process/cbits/runProcess.c.

The simplest fix appears to be to declare these external functions with an
unspecified argument list rather than a void argument list.  This is no
worse for platforms that don't care either way, and allows a successful
bootstrap of GHC 7.8 on little-endian Linux ppc64 (which uses the ELFv2
ABI).

Fixes #8965

Signed-off-by: Colin Watson <cjwatson@debian.org>
Signed-off-by: Austin Seipp <austin@well-typed.com>
(cherry picked from commit 5a31f231eebfb8140f9b519b166094d9d4fc2d79)
Add the powerpc64le architecture

This is ArchUnknown for now, as it requires some porting work over and
above powerpc64 due to such things as the different function calling
sequence in the ELFv2 ABI.  For now, an unregisterised port is better
than nothing.

Signed-off-by: Colin Watson <cjwatson@debian.org>
Signed-off-by: Austin Seipp <austin@well-typed.com>
(cherry picked from commit 8586f600613a6a99fee8fe707b00adab1a340641)
ghc: Do not add a space in '-U __PIC__'

GHC previously introduced a space here. However, this can in some cases
be interpreted as "-U __PIC__" - note that in shell, the -U would still
be recognized with an argument, but the argument would be " __PIC__",
with a space in front, as opposed to the single string '__PIC__'.

In practice most tools seem to handle this OK. But the Coverity Scan
analysis tool does not: it errors on the fact that ' __PIC__' is an
invalid CPP name to undefine.

With this, it seems the Coverity analysis tool can easily analyze the
entire GHC build.

Signed-off-by: Austin Seipp <austin@well-typed.com>
(cherry picked from commit 574ef4293b867609f2d28d85747e01f3ac0d052d)
Kill whitespace after cpp's `-I` flag

This clean-up is in a similiar spirit as 574ef4293b8676.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
(cherry picked from commit 4ab8fc55eb6119dbba2f487c5a01d30a7c6ae113)
Zonk the existential type variables in tcPatSynDecl

This was just an omission, which showed up as Trac #8966

(cherry picked from commit 4dc9f9869bfc82fdb8bd61864859007873ebcc27)
Simplify and tidy up the handling of tuple names

This fixes Trac #8954.

There were actually three places where tuple occ-names
were parsed:
  - IfaceEnv.lookupOrigNameCache
  - Convert.isBuiltInOcc
  - OccName.isTupleOcc_maybe

I combined all three into TysWiredIn.isBuiltInOcc_maybe
Much nicer.

(cherry picked from commit 750271e61bdbaad50c19176406512e79abe404a8)

Conflicts:
	testsuite/tests/th/all.T
Honour the untouchability of kind variables

Trac #8985 showed up a major shortcoming in the kind unifier: it was
ignoring untoucability.  This has unpredictably-bad consequences;
notably, the skolem-escape check can fail.

There were two things wrong
 * TcRnMonad.isTouchableTcM was returning a constant value for kind variables
   (wrong), and even worse the constant was back-to-front (it was always False).

 * We weren't even calling isTouchableTcM in TcType.unifyKindX.

I'm not sure how this ever worked.

Merge to 7.8.3 in due course.

(cherry picked from commit e7f0ae7ff4f2199abe42f20bac825a7802bff466)