This is a very temporary, very unsatisfactory hack to fix #5987
(for now.)

The included comments essentially say it all: we lower the unfolding
threshold to minimize some amount of exported symbols from the GHC
stage2 DLL. I unfortunately had to lower it quite substantially for the
dynamic stage2 build to pass.

As of this writing, the DLL split between ghc.dll and ghc-0.dll is
something like 26,000 vs 63,000 exported symbols, respectively. So we're
still quite in danger of tripping it, but I think we will be OK at this
exact moment.

Signed-off-by: Austin Seipp <austin@well-typed.com>

This is suitable e.g. for iOS.

Authored-by: Authored-by: Luke Iannini <lukexi@me.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

This patch implements a warning when definitions conflict with the
Applicative-Monad Proposal (AMP), described in #8004. Namely, this will
cause a warning iff:

    * You have an instance of Monad, but not Applicative
    * You have an instance of MonadPlus, but not Alternative
    * You locally defined a function named join, <*>, or pure.

In GHC 7.10, these warnings will actually be enforced with superclass
constraints through changes in base, so programs will fail to compile
then.

This warning is enabled by default. Unfortunately, not all of
our upstream libraries have accepted the appropriate patches. So we
temporarily fix ./validate by ignoring the AMP warning.

Dan Rosén made an initial implementation of this change, and the
remaining work was finished off by David Luposchainsky. I finally made
some minor refactorings.

Authored-by: Dan Rosén <danr@chalmers.se>
Authored-by: David Luposchainsky <dluposchainsky@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

Parser.hs needs to be compiled with -fcmm-sink on x86 platforms, so the
register allocator doesn't run out of stack slots. Previously, we had to
do some CPP hacks in order to emit an #ifdef into the file - this is
because we preprocess it once up front, and run the preprocessor again
when we compile it.

There's two cases: the boostrap compiler is > 7.8, and the stage1 parser
needs the flag, or the stage1 compiler is compiling the stage2
Parser.hs, and needs the flag..

The previous approach was super fragile with Clang. The more principled
fix is to instead do this through the build system.

This fixes #8182.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

For some reason, the new `GccIsClang` variable introduced via
fc4856f9 for addressing #8148
isn't set explicitly to `NO`; so this simply changes the test
`ifeq $(GccIsClang) NO` to `ifneq $(GccIsClang) YES` which
should fix the build with and w/o Clang.

* This partially fixes #8148. However, --with-ghc-4.8 will still not work given the rather dubious m4 macros and the failures in the test suite due to '-nodefaultlibs' still need to be fixed.

Fixing #8217 for the unix(-like) case.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

The iOS simulator is essentially an iOS target but for an x86 machine
instead. It doesn't support the native code generator either, though.

Authored-by: Stephen Blackheath <...@blacksapphire.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>

When cross compiling to iOS, we generate archive files which are linked
into the final executable. We already *did* generate archive files -
just with the wrong suffix.

Fixes #8125.

Authored-by: Stephen Blackheath <...@blacksapphire.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Dynamic libraries on powerpc linux are currently broken.
See: http://hackage.haskell.org/trac/ghc/ticket/8024

On Windows, the ranlib in the path may not be the right ranlib (it may
be the 32bit ranlib when we are making a Win64 compiler, or vice-versa).
Therefore we can't leave it up to libffi to detect the right ranlib, but
need to tell it which ranlib to use. This means that we need to find
ranlib even if we don't actually need it ourselves.

It likes to think lambdas a la:

    foo $ \u -> ...

represent a kind of unicode extended literal.

It also gets confused when you have things like:

    ... thing ... {- comment ... (???) -}

where the (???) is mistaken as a trigraph.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

We now check in the same way that the testsuite does.

The LLVM back end does not yet work when building dynamically.

kgardas authored 12 years ago and ian@well-typed.com committed 12 years ago

This patch disables shared libs support on arm-unknown-linux platform. It
unbreaks ghc-stage2 on this platform after recent Ian's changes
in dynamic/shared libs domain. The reason why ghc-stage2 fails when linked
with shared libs is still unknown so this is just a workaround at the moment,
but it at least recovers previous "correct" behavior of ghc-stage2
on ARM/Linux

People are probably more likely to notice some useful variables
if they're located closer to the top (like V=0 and stage=2.)

Signed-off-by: Austin Seipp <aseipp@pobox.com>

properly (see #7819)

Patch from Stephen Blackheath.

Currently they are all set to the same value, but when cross-compiling
they could be set to different values.

We now leave making installers to the Haskell Platform.

Although it's not technically needed, it's less confusing if the vanilla
way works when people use the sample build.mk.

  * the new StgCmmArgRep module breaks a dependency cycle; I also
    untabified it, but made no real changes

  * updated the documentation in the wiki and change the user guide to
    point there

  * moved the allocation enters for ticky and CCS to after the heap check

    * I left LDV where it was, which was before the heap check at least
      once, since I have no idea what it is

  * standardized all (active?) ticky alloc totals to bytes

  * in order to avoid double counting StgCmmLayout.adjustHpBackwards
    no longer bumps ALLOC_HEAP_ctr

  * I resurrected the SLOW_CALL counters

    * the new module StgCmmArgRep breaks cyclic dependency between
      Layout and Ticky (which the SLOW_CALL counters cause)

    * renamed them SLOW_CALL_fast_<pattern> and VERY_SLOW_CALL

  * added ALLOC_RTS_ctr and _tot ticky counters

    * eg allocation by Storage.c:allocate or a BUILD_PAP in stg_ap_*_info

    * resurrected ticky counters for ALLOC_THK, ALLOC_PAP, and
      ALLOC_PRIM

    * added -ticky and -DTICKY_TICKY in ways.mk for debug ways

  * added a ticky counter for total LNE entries

  * new flags for ticky: -ticky-allocd -ticky-dyn-thunk -ticky-LNE

    * all off by default

    * -ticky-allocd: tracks allocation *of* closure in addition to
       allocation *by* that closure

    * -ticky-dyn-thunk tracks dynamic thunks as if they were functions

    * -ticky-LNE tracks LNEs as if they were functions

  * updated the ticky report format, including making the argument
    categories (more?) accurate again

  * the printed name for things in the report include the unique of
    their ticky parent as well as if they are not top-level

We were only setting an RPATH for the RTS DLL on Linux, but as far
as I can see we should be doing it for all ELF OSes. Hopefully this
will fix the problem where the installed ghc-pkg can't find libffi.dll
on FreeBSD.

Pretty much everything does now, so list those that don't instead
instead of listing those that do.

Technically we don't need the v way, but with -dynamic-too it's cheap,
and having it makes life easier.

It doesn't work yet

In particular, this means that GHCi will use DLLs, rather than loading
object files itself.

Signed-off-by: David Waern <david.waern@gmail.com>

It's only actually used if both the v and dyn ways are built

We no longer set BootingFromHc