GitLab

Summary:
get/setAllocationCounter didn't take into account allocations in the
current block. This was known at the time, but it turns out to be
important to have more accuracy when using these in a fine-grained
way.

Test Plan:
New unit test to test incrementally larger allocaitons.  Before I got
results like this:

```
+0
+0
+0
+0
+0
+4096
+0
+0
+0
+0
+0
+4064
+0
+0
+4088
+4056
+0
+0
+0
+4088
+4096
+4056
+4096
```

Notice how the results aren't always monotonically increasing.  After
this patch:

```
+344
+416
+488
+560
+632
+704
+776
+848
+920
+992
+1064
+1136
+1208
+1280
+1352
+1424
+1496
+1568
+1640
+1712
+1784
+1856
+1928
+2000
+2072
+2144
```

Reviewers: hvr, erikd, simonmar, jrtc27, trommler

Reviewed By: simonmar

Subscribers: trommler, jrtc27, rwbarton, thomie, carter

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

This is required by D4288. However, this only handles i386; we will
likely also need to do the same for PPC and SPARC, lest they break when
D4288 is re-merged.

Test Plan: Validate

Reviewers: simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

Support for signed conversion from 32 bit to 64 bit
integers is required by D4363.

Test Plan: validate (perhaps also on SPARC)

Reviewers: simonmar, bgamari, kgardas, jrtc27

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

This is required by D4363. D4362 has the implementation for i386
this commit adds PowerPC.

Test Plan: validate

Reviewers: erikd, hvr, simonmar, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

Provide flag for showing showing Word# and Word64# as hexadecimal when
dumping GHC core.  The only affects Word, not Int, and it prefixes the
hexadecimal with enough zeroes to make the total character count a power
of two. For example:

- 0x0C0C instead of 0xC0C
- 0x00BA00BA instead of 0xBA00BA

This also affects the presentation of Word# and Word64# in GHC's error
messages. It is not expected that the flag will be used for this, but
it is a side-effect worth noting.

Test Plan: none

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, mpickering, rwbarton, thomie, carter, andrewthad

GHC Trac Issues: #14872

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

- Fix the naming and comments to indicate that we are calculating
  *reverse* postorder (and not the standard postorder).

- Rewrite the calculation to avoid CPS code. I found it fairly
  difficult to understand and the new one seems faster (according to
  nofib, decreases compiler allocations by 0.2%)

- Remove `LabelsPtr`, which seems unnecessary and could be *really*
  confusing. For instance, previously:
  `postorder_dfs_from <block with label X>`
  and
  `postorder_dfs_from <label X>`
  would actually mean quite different things (and give different
  results).

- Change the `Dataflow` module to always use entry of the graph for
  reverse postorder calculation. This should be the only change in
  behavior of this commit.

  Previously, if the caller provided initial facts for some of the
  labels, we would use those labels for our postorder calculation.
  However, I don't think that's correct in general - if the initial
  facts did not contain the entry of the graph, we would never analyze
  the blocks reachable from the entry but unreachable from the labels
  provided with the initial facts. It seems that the only analysis that
  used this was proc-point analysis, which I think would always include
  the entry block (so I don't think there's any bug due to this).
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate

Reviewers: bgamari, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

This removes a bunch of unnecessary includes of `HsVersions.h` along
with unnecessary CPP (e.g., due to checking for DEBUG which can be
achieved by looking at `debugIsOn`)
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

Pretty-print unused imported names unqualified unconditionally to
make the warning message consistent for ambiguous/unambiguous
identifiers.
Signed-off-by: HE, Tao <sighingnow@gmail.com>

Test Plan: make test TEST="T14881"

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #14881

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

Test Plan: validate

Reviewers: bgamari, AndreasK, erikd

Reviewed By: AndreasK

Subscribers: rwbarton, thomie, carter

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

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

The existing internal counters:
* gc_alloc_block_sync
* whitehole_spin
* gen[g].sync
* gen[1].sync

are now not shown in the -s report unless --internal-counters is also passed.

If --internal-counters is passed we now show the counters above, reformatted, as
well as several other counters. In particular, we now count the yieldThread()
calls that SpinLocks do as well as their spins.

The added counters are:
* gc_spin (spin and yield)
* mut_spin (spin and yield)
* whitehole_threadPaused (spin only)
* whitehole_executeMessage (spin only)
* whitehole_lockClosure (spin only)
* waitForGcThreadsd (spin and yield)

As well as the following, which are not SpinLock-like things:
* any_work
* do_work
* scav_find_work

See the Note for descriptions of what these counters are.

We add busy_wait_nops in these loops along with the counter increment where it
was absent.

Old internal counters output:
```
gc_alloc_block_sync: 0
whitehole_gc_spin: 0
gen[0].sync: 0
gen[1].sync: 0
```

New internal counters output:
```
Internal Counters:
                                           Spins        Yields
    gc_alloc_block_sync                      323             0
    gc_spin                              9016713           752
    mut_spin                            57360944         47716
    whitehole_gc                               0           n/a
    whitehole_threadPaused                     0           n/a
    whitehole_executeMessage                   0           n/a
    whitehole_lockClosure                      0             0
    waitForGcThreads                           2           415
    gen[0].sync                                6             0
    gen[1].sync                                1             0

    any_work                                2017
    no_work                                 2014
    scav_find_work                          1004
```

Test Plan:
./validate

Check it builds with #define PROF_SPIN removed from includes/rts/Config.h

Reviewers: bgamari, erikd, simonmar, hvr

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #3553, #9221

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

Make sure it runs with --fast validate with correct optimisation
settings (-O1 or above) so that it actually tests the bug.

Because the bug is in the simplifier running it with -O0 doesn't
test it.

Related to Ryan's upcoming patch for Trac #14933

ghc treats OSUnknown (and GNU/Hurd) as non-ELF target.
This causes panic in native codegenerator when trying
to build PIC code:

```
  ...
  -- all other platforms
  howToAccessLabel dflags _ _ _ _ _
        | not (positionIndependent dflags)
        = AccessDirectly
        | otherwise
        = panic "howToAccessLabel: PIC not defined for this platform"
```

This change declares new 'OSHurd' and marks it as an
ELF target. Fixes building ghc-stage2 on i686-unknown-gnu0.9.

Patch provided by "Pino" via Samuel Thibault and taken from
debian.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Running plain ./configure fails on hurd because
./config.guess reports unrecognised tuple:
    $ ./config.guess
    i686-unknown-gnu0.9

The change makes the following target configure:
$ ./configure --target=i686-unknown-gnu0.9
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Given this program:

    main = do
      f $ do
        a <- return 3
          c <- do
          return 5

GHC previously gave this error message:

    Main.hs:2:7: error:
        Parse error in pattern: do a <- return 3 c
        Possibly caused by a missing 'do'?
      |
    2 |   f $ do
      |       ^^...

What happened is GHC considered the whole `f $ do a <- return 3 c` as a
pattern. When parsed as an expression it becomes an infix application of
`($)`, and GHC checks left and right hand sides before checking if `($)`
is a valid infix constructor name, and shows the first error it got.

If instead we first check if the infix op is valid in pattern context,
the error message becomes much clearer:

    Main.hs:2:3: error:
        Parse error in pattern: f $ do a <- return 3 c
        Possibly caused by a missing 'do'?
      |
    2 |   f $ do
      |   ^^^^^^...

This may not entirely fix #11188 but I think it's an improvement.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #11188

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

GHC 8.4.1 is out, so now GHC's support window only extends
back to GHC 8.2. This means we can delete gobs of code that were
only used for GHC 8.0 support. Hooray!

Test Plan: ./validate

Reviewers: bgamari, erikd, dfeuer

Reviewed By: bgamari, dfeuer

Subscribers: alexbiehl, dfeuer, rwbarton, thomie, carter

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

[skip ci]

[skip ci]

T13615 needs multicore support from RTS:
    T13615: unknown RTS option: -N15
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

When interpreter is not profiled (see `interpreterProfiled` in
`DynFlags`) bytecode generator generates a NULL pointer as the cost
centre of a `BRK_FUN` instruction:

    let cc | interpreterProfiled dflags = cc_arr ! tick_no
           | otherwise = toRemotePtr nullPtr
    let breakInstr = BRK_FUN (fromIntegral tick_no) (getUnique this_mod) cc
    return $ breakInstr `consOL` code

We now take this into account when disassembling `BRK_FUN`.

Reviewers: bgamari, simonmar, erikd

Subscribers: rwbarton, thomie, carter

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

Unreg build failed as:

  $ ./configure --enable-unregisterised
  $ make

  HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o
    ghc_1.hc: In function 'ghczmprim_GHCziPrimopWrappers_pdep8zh_entry':

    ghc_1.hc:1810:9: error:
     error: implicit declaration of function 'hs_pdep8'; did you mean 'hs_ctz8'?
       [-Werror=implicit-function-declaration]
     _c3jz = hs_pdep8(*Sp, Sp[1]);
             ^~~~~~~~
             hs_ctz8
       |
  1810 | _c3jz = hs_pdep8(*Sp, Sp[1]);
       |         ^
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: New unit test

Reviewers: andrewthad, niteria, bgamari, erikd

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14900

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

Reviewers: hvr

Subscribers: rwbarton, thomie, erikd, carter

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

In commit 503219e3, we
stopped suppressing `-Wmissing-methods` warnings on class methods
whose names begin with an underscore. However, it seems the users'
guide documentation concerning this was never updated. Let's do so.

Test Plan: Read it

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #12959

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

GCC throws this warning to inform us that __sync_fetch_and_nand's
behavior changed in GCC 4.4. However, this causes the build to fail when
-Werror is used.

Test Plan: Validate with -Werror

Subscribers: rwbarton, thomie, carter

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

As described in https://bugs.llvm.org/show_bug.cgi?id=8842, Clang
removed the __sync_fetch_and_nand builtins due to inconsistency in GCC's
behavior in 2010.  However, GCC has since clarified the behavior of
their builtins and consequently Clang re-added them in 2014.
Consequently this workaround should no longer be necessary.

Test Plan: Validate building with Clang

Subscribers: rwbarton, thomie, carter

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

- Show a more friendly error message when -fplugin is used with
  -fexternal-interpreter

- Add a few words to users guide about the interaction with -fplugin and
  -fexternal-interpreter

- Update test for #14335

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14335

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

This reverts commit 59d7ee53 and enables
the test for #14052.

(See #14052 for the discussion)

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14052

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

Summary:
The `-dynamic` flag does two things:

* In the code generator, it generates code designed to link against
  external shared libraries.  References outside of the current module
  go through platform-specific indirection tables (e.g. the GOT on ELF).

* It enables a "way", which changes which hi files we look
  for (`Foo.dyn_hi`) and which libraries we link against.

Some specialised applications want the first of these without the
second. (I could go into detail here but it's probably not all that
important).

This diff splits out the code-generation effects of `-dynamic` from the
"way" parts of its behaviour, via a new flag `-fexternal-dynamic-refs`.

Test Plan: validate

Reviewers: niteria, bgamari, erikd

Subscribers: rwbarton, thomie, carter

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

Windows support was added in c93813d9

That image creates an unprivileged user to run the test suite under.