GitLab

Since some ELF fields ran out of range to represent that many sections,
they've been extended with magic numbers that indicate that the full
value is stored in another field.

This will be necessary for GHCi with -split-sections on ELF platforms
that don't use GNU ld.

Reviewers: austin, bgamari, simonmar, erikd

Reviewed By: bgamari, simonmar, erikd

Subscribers: thomie

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

GHC Trac Issues: #8405

Test Plan: Build with Clang and GCC

Reviewers: austin, thomie, hvr, bgamari

Reviewed By: bgamari

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

Another weird case of Clang not accepting whitespace in CPP that
GCC accepts without a problem.

Test Plan: Build with Clang and GCC

Reviewers: austin, thomie, hvr, bgamari

Reviewed By: bgamari

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

Summary:
This patch disables large address space on OpenBSD. The motivation
for this is that OpenBSD does not support MAP_NORESERVE. The flag is supported
only for source code compatibility reasons but is otherwise completely ignored
by the OS and its mmap syscall.

Reviewers: austin, bgamari

Subscribers: thomie, erikd

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

This change mirrors the change that occured for the recent
`semigroups-0.18` release, i.e.

  https://github.com/ekmett/semigroups/commit/7a000212847b0d309892f34e4754a25ddec7100b

This removal addresses concerns raised in #10365

Summary:
Fix building new Sphinx documenation on Windows in msys2 using Awson's patch on #11021.

Install Sphinx using `pacman -S mingw-w64-$(uname -m)-python2-sphinx`

Test Plan: Apply patch and ./validate

Reviewers: thomie, bgamari, austin

Reviewed By: thomie, bgamari

Subscribers: erikd

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

GHC Trac Issues: #11021

Starting with directory-1.2.5 there will be a nameclash with
`withCurrentDirectory` and `MIN_VERSION_filepath()` isn't available at
bootstrap-time with the current GHC build-system.

By using explicit import lists we avoid CPP altogether

This adds a subWordC# primop which implements subtraction with overflow
reporting.

Reviewers: tibbe, goldfire, rwbarton, bgamari, austin, hvr

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #10962

This is needed to prepare for #11026 as this update
relaxes the upper bounds on `base` to allow for `base-4.9.0.0`

This is needed to prepare for #11026 as these updates
relax the upper bounds on `base` to allow for `base-4.9.0.0`

The patch makes
    $ make test TEST="debug T10667"
not to fail on CmmStack code generation phase
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

When generating dictionary let binds in dsTcEvBinds we may
end up generating them in arbitrary order according to Unique order.

Consider:

```
let $dEq = GHC.Classes.$fEqInt in
let $$dNum = GHC.Num.$fNumInt in ...
```

vs

```
let $dNum = GHC.Num.$fNumInt in
let $dEq = GHC.Classes.$fEqInt in ...
```

The way this change fixes it is by using `UniqDFM` - a type of
deterministic finite maps of things keyed on `Unique`s. This way when
you pull out evidence variables corresponding to type-class dictionaries
they are in deterministic order.

Currently it's the order of insertion and the way it's implemented is by
tagging the values with the time of insertion.

Test Plan:
I've added a new test case to reproduce the issue.
./validate

Reviewers: ezyang, simonmar, austin, simonpj, bgamari

Reviewed By: simonmar, simonpj, bgamari

Subscribers: thomie

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

GHC Trac Issues: #4012

Reviewers: austin, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11039

Previously this was introduced in D524 as a compile-time constant.
Sadly, this isn't flexible enough to allow for environments where
ulimits restrict the maximum address space size (see, for instance,

Consequently, we are forced to make this dynamic. In principle this
shouldn't be so terrible as we can place both the beginning and end
addresses within the same cache line, likely incurring only one or so
additional instruction in HEAP_ALLOCED.

Test Plan: validate

Reviewers: austin, simonmar

Reviewed By: simonmar

Subscribers: thomie

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

GHC Trac Issues: #10877

Summary:
This commit reimplements shadowing on package databases by doing
the shadowing calculation on a per-database basis: specifically,
if a later package database shadows a package from the earlier
databases, we first remove that package (and its transitive
dependencies) before merging the databases together.

This should also fix bootstrapping GHC HEAD with HEAD.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: ggreif, bgamari, austin

Subscribers: thomie

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

This is the second attempt at merging D757.

This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.

However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.

See particularly

 * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
 * Note [The overall promotion story] in DataCon (clarifies existing
stuff)

The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:

 * We need to have enough data types around to *define* a TyCon
 * Many of these types are wired-in

Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.

Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969

 * T1969:    GHC allocates 19% more
 * T4801:    GHC allocates 13% more
 * T5321FD:  GHC allocates 13% more
 * T9675:    GHC allocates 11% more
 * T783:     GHC allocates 11% more
 * T5642:    GHC allocates 10% more

I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.

Remaining to do
~~~~~~~~~~~~~~~

 * I think that "TyCon" and "Module" are over-generic names to use for
   the runtime type representations used in GHC.Typeable. Better might
be
   "TrTyCon" and "TrModule". But I have not yet done this

 * Add more info the the "TyCon" e.g. source location where it was
   defined

 * Use the new "Module" type to help with Trac Trac #10068

 * It would be possible to generate TyConRepName (ie Typeable
   instances) selectively rather than all the time. We'd need to persist
   the information in interface files. Lacking a motivating reason I
have
   not done this, but it would not be difficult.

Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular

 * In TyCon, a type *family* (whether type or data) is repesented by a
   FamilyTyCon
     * a algebraic data type (including data/newtype instances) is
       represented by AlgTyCon This wasn't true before; a data family
       was represented as an AlgTyCon. There are some corresponding
       changes in IfaceSyn.

     * Also get rid of the (unhelpfully named) tyConParent.

 * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
   optionally promoted; and use it elsewhere in GHC.

 * Cleanup handling of knownKeyNames

 * Each TyCon, including promoted TyCons, contains its TyConRepName, if
   it has one. This is, in effect, the name of its Typeable instance.

Updates haddock submodule

Test Plan: Let Harbormaster validate

Reviewers: austin, hvr, goldfire

Subscribers: goldfire, thomie

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

GHC Trac Issues: #9858

Test Plan: it works

Reviewers: bgamari, rwbarton, austin

Reviewed By: austin

Subscribers: rwbarton

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

Previously the `.debug-ghc-link-info` section was of type `SHT_NOTE` but
this is not compliant with the ELF specification, which requires that
`NOTE` sections are in a particular record-based format. We mark this
section as `PROGBITS` instead, which is defined as implying no
particular format.

Fixes #11022.

Reviewers: bgamari, austin

Reviewed By: bgamari, austin

Subscribers: thomie, hsyl20

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

GHC Trac Issues: #11022

This allows it to be used by users and packagers to grab the tarballs
necessary to generate a source tarball.

Test Plan: try it

Reviewers: thomie, austin, Phyx

Reviewed By: thomie, austin, Phyx

Subscribers: erikd

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

Reviewers: simonpj, austin

Reviewed By: austin

Subscribers: thomie

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

(Simplifier and desugarer do this already)

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Test Plan: Validate on powerpc/linux, x86_64/linux and x86_64/darwin

Reviewers: austin, bgamari, thomie

Reviewed By: thomie

Subscribers: Phyx, thomie

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

Make various population count operations available via C-- syntax
under the names %popcnt{8,16,32,64}. Fixes #11037.

Reviewers: simonmar, austin, ekmett

Reviewed By: austin, ekmett

Subscribers: thomie

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

GHC Trac Issues: #11037

It was possible to read non-existent memory, if we try to read the
srt_offset field of an info table when there is no SRT, and the info
table is right at the start of the text section.

This actually happened to me, I'm not sure why it never happened
before.

Test Plan: validate

Reviewers: rwbarton, ezyang, austin, bgamari

Reviewed By: austin, bgamari

Subscribers: thomie

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

This is needed for #10374 (but doesn't fix it yet).

Also rename DeriveConstants.hs to Main.hs, because the build
system has trouble with Main modules not called Main.hs.

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

The build system has trouble with Main modules not called Main.hs. This
change allows a hack in utils/runghc/ghc.mk to be removed.

This makes DuplicateRecordFields more liberal in when it will
accept ambiguous record selectors, making use of type information in a
similar way to updates. See Note [Disambiguating record fields] for more
details. I've also refactored how record updates are disambiguated.

Test Plan: New and amended tests in overloadedrecflds

Reviewers: simonpj, goldfire, bgamari, austin

Subscribers: thomie

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

I don't really understand this.  GHC.hs had:

  module GHC( ...,  module HsSyn, ... ) where
    import HsSyn
    import qualified HsSyn -- hack as we want to reexport the whole module

GHC now reports the 'import qualified' line as redundant; and it certainly
is, because 'import HsSyn' brings everything into scope qualified *and*
unqualified.   I have no idea why the "hack" was necessary before, but
following my refactoring of tcg_used_gres (previous commit), it's reported
as redundant, so I've deleted it.

I'm making it a separate commit because it seems a bit mysterious and I
wanted to draw attention to it.

This patch implements an improvment that I've wanted to do for ages, but
never gotten around to.

Unused imports are computed based on how imported entities occur (qualified,
unqualified).   This info was accumulated in tcg_used_rdrnames :: Set RdrName.
But that was a huge pain, and it got worse when we introduced duplicate
record fields.

The Right Thing is to record tcg_used_gres :: [GlobalRdrElt], which records
the GRE *after* filtering with pickGREs.  See Note [GRE filtering] in RdrName.
This is much, much bette.  This patch deletes quite a bit of code, and is
conceptually much easier to follow.

Hooray.  There should be no change in functionality.

The fix for Trac #10890 in commit 1818b48e, namely
   Fix incorrect import warnings when methods with identical names are imported
was wrong, as demonstrated by the new test T10890_2.  It suppressed
far too many warnings!

This patch fixes the original problem in a different way, by making
RdrName.greUsedRdrName a bit cleverer.

But this too is not really the Right Thing.  I think the Right Thing is
to store the /GRE/ in the tcg_used_rdrnames, not the /RdrName/.  That
would be a lot simpler and more direct.

But one step at a time.

This is a follow on to the patch for Trac #10928.
It's a local renaming of variables only; no change in behaviour.

The code:

    uint64_t c = __sync_sub_and_fetch((uint64_t*)addr, 1);

was causing GCC to emit atomic instructions for 64 bit values which
are not available on PowerPC. However, since PowerPC only has a 32
bit address space, use of a 64 bit value is superflous.

Switching the type from `uint64_t` to `uintptr_t` should simply do
the correct thing on all 32 and 64 bit architectures.

Reviewers: austin, bgamari, simonmar

Subscribers: thomie

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

GHC Trac Issues: #11036

The following source snippet 'module A where x */* y = 42'
when being compiled with '-g' option emits syntactically
invalid comment for GNU as:

    .text
        .align 8
        .loc 1 3 1 /* */* */

Fixed by not emitting comments at all. We already suppress
all asm comments in 'X86/Ppr.hs'.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Test Plan: added test and check it works

Reviewers: scpmw, simonmar, austin, bgamari

Reviewed By: simonmar

Subscribers: thomie

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

GHC Trac Issues: #10667

This reverts commit bef2f03e.

This merge was botched

Also reverts haddock submodule.

This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.

However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.

See particularly

 * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
 * Note [The overall promotion story] in DataCon (clarifies existing stuff)

The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:

 * We need to have enough data types around to *define* a TyCon
 * Many of these types are wired-in

Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.

Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969

 * T3294:   GHC allocates 110% more (filed #11030 to track this)
 * T1969:   GHC allocates 30% more
 * T4801:   GHC allocates 14% more
 * T5321FD: GHC allocates 13% more
 * T783:    GHC allocates 12% more
 * T9675:   GHC allocates 12% more
 * T5642:   GHC allocates 10% more
 * T9961:   GHC allocates 6% more

 * T9203:   Program allocates 54% less

I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.

Remaining to do
~~~~~~~~~~~~~~~

 * I think that "TyCon" and "Module" are over-generic names to use for
   the runtime type representations used in GHC.Typeable. Better might be
   "TrTyCon" and "TrModule". But I have not yet done this

 * Add more info the the "TyCon" e.g. source location where it was
   defined

 * Use the new "Module" type to help with Trac Trac #10068

 * It would be possible to generate TyConRepName (ie Typeable
   instances) selectively rather than all the time. We'd need to persist
   the information in interface files. Lacking a motivating reason I have
   not done this, but it would not be difficult.

Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular

 * In TyCon, a type *family* (whether type or data) is repesented by a
   FamilyTyCon
     * a algebraic data type (including data/newtype instances) is
       represented by AlgTyCon This wasn't true before; a data family
       was represented as an AlgTyCon. There are some corresponding
       changes in IfaceSyn.

     * Also get rid of the (unhelpfully named) tyConParent.

 * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
   optionally promoted; and use it elsewhere in GHC.

 * Cleanup handling of knownKeyNames

 * Each TyCon, including promoted TyCons, contains its TyConRepName, if
   it has one. This is, in effect, the name of its Typeable instance.

Requires update of the haddock submodule.

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