GitLab

Problems were found on 32-bit platforms, I'll commit again when I have a fix.

This reverts the following commits:
   54b31f74
   b0534f78

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

Commit  b0534f78 added new exported rts symbols,
but slightly misspelled them.

Observer on first compiled program:
> Linking dist/build/haskell-updater/haskell-updater ...
> /usr/lib64/ghc-7.9.20140503/rts-1.0/libHSrts.a(Schedule.o): In function `scheduleWaitThread':
> (.text+0xc4c): undefined reference to `base_GHCziIOziException_allocationLimitExceeded_closure'
> /usr/lib64/ghc-7.9.20140503/rts-1.0/libHSrts.a(RtsStartup.o): In function `hs_init_ghc':
> (.text+0x2fa): undefined reference to `base_GHCziIOziException_allocationLimitExceeded_closure'
> collect2: error: ld returned 1 exit status

CC: Simon Marlow <marlowsd@gmail.com>
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

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

This tracks the amount of memory allocation by each thread in a
counter stored in the TSO.  Optionally, when the counter drops below
zero (it counts down), the thread can be sent an asynchronous
exception: AllocationLimitExceeded.  When this happens, given a small
additional limit so that it can handle the exception.  See
documentation in GHC.Conc for more details.

Allocation limits are similar to timeouts, but

  - timeouts use real time, not CPU time.  Allocation limits do not
    count anything while the thread is blocked or in foreign code.

  - timeouts don't re-trigger if the thread catches the exception,
    allocation limits do.

  - timeouts can catch non-allocating loops, if you use
    -fno-omit-yields.  This doesn't work for allocation limits.

I couldn't measure any impact on benchmarks with these changes, even
for nofib/smp.

As suggested in #9057.

The function was inlined at two places already. And the function is
having the STATIC_INLINE annotation, so the assembly output should.
be the same.

To convince myself, I did diff the output of the object files before
and after the patch and they matched on my 64-bit Ubuntu 13.10 machine,
running gcc 4.8.1-10ubuntu9.

Also, I had to move scavenge_small_bitmap up a bit since it's not in any
.h-file.

While I was at it, I also applied the analogous patch for Compact.c.
Though I had to write `thread_small_bitmap` instead of just moving it.

A long debate is in issue #8742, but the main motivation is that this
allows for applying a patch to reuse the function scavenge_small_bitmap
without changing the .o-file output.

Similarly, I changed the types in rts/sm/Compact.c, so I can create
a STATIC_INLINE function for the redundant code block:

        while (size > 0) {
            if ((bitmap & 1) == 0) {
                thread((StgClosure **)p);
            }
            p++;
            bitmap = bitmap >> 1;
            size--;
        }

Issue discovered by Coverity Scan, CID 43168.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Issue discovered by Coverity Scan, CID 43171.
Signed-off-by: Austin Seipp <austin@well-typed.com>

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

This commit also makes better names for several of these functions,
and removes one that went unused.

This reverts commit 4539400a.

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

The new stg_gc_prim_p_ll stack frame was missing an info table.  This
is a regression since 7.6, because this stuff was part of a cleanup
that happened in 7.7.

This is the result of an email conversation (off list) with
Conal Elliott, who needed a stronger unSubCo_maybe. This
commit adds cases to upgrade the role of a coercion when
recursion is necessary to do say (for example, for a use of
TransCo). As a side effect, more coercion optimizations are
now possible.

This was not done previously because unSubCo_maybe was used
only during coercion optimization, and the recursive cases
looked to be unlikely. However, adding them can cause no harm.

unSubCo_maybe is now also exported from Coercion, for use
cases like Conal's.

We now display the foralls of a type if any of the type variables
is polykinded.  This put kind polymorphism "in your face" a bit more
often, but eliminates a lot of head scratching.

The user manual reflects the new behaviour.

The provided tests test both annotation generation and reification
from Template Haskell.  Both --make and compilation via separate
units (ghc -c) are tested.
Signed-off-by: Austin Seipp <austin@well-typed.com>

The reifyAnnotation method of the Q monad correctly gathered annotations
from TCG and EPS.  Unfortunately it didn't look into the Home Package
Table.  This resulted in annotations not being found if they are in the
same package as the splice that is reifying and ghc --make is used for
compilation management.  Fix this by using the already existing
prepareAnnotations method from HscTypes.lhs that correctly searches
in HPT and EPS both.
Signed-off-by: Austin Seipp <austin@well-typed.com>

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

Many of these have never been initialised, I think.  They
were simply guesses from the 64-bit version.

The argument in Trac #9033 is very compelling: we should not report 20
errors, fix one, and have the other 19 disappear.  They were spurious
in the first place.

The fix was easy; do type-class defaulting uncondionally, rather than
only if there are no insoluble constraints.

See Note [When to do type-class defaulting] in TcSimplify.

Error messages generally improve, especially tc211 which actually
had an example of precisely this phenomenon.

The Commentary is now on the wiki and far more complete. This copy will
of course live on in the annals of history, but there's no reason to
keep it around still.
Signed-off-by: Austin Seipp <austin@well-typed.com>

`make clean` did already ignore a missing mk/config.mk,
but `make distclean` and `make maintainer-clean` didn't.
This commit rectifies this oversight.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

Issue discovered by Coverity scan, CID 43167.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Issue discovered by Coverity scan, CID 43163. This should fix CID 43172 as a
side-effect as well.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Issue discovered by Coverity scan, CID 43165.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Issue discovered by Coverity scan, CID 43142.
Signed-off-by: Austin Seipp <austin@well-typed.com>

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

n_capabilities is declared as unsigned int (32bit), and so multiplication
is 32-bit before being stored in a 64bit integer (StgWord).

Instead, cast n_capabilities to StgWord before multiplying.

Discovered by Coverity. CID 43164.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Discovered by Coverity. CID 43166.
Signed-off-by: Austin Seipp <austin@well-typed.com>