Skip to content

GitLab

GHC
GHC
Switch branch/tag
  1. 13 Oct, 2015 1 commit
    • Erik de Castro Lopo's avatar
      Switch to LLVM version 3.7 · 29310b62
      Erik de Castro Lopo authored 
      Before this commit, GHC only supported LLVM 3.6. Now it only supports
LLVM 3.7 which was released in August 2015. LLVM version 3.6 and earlier
do not work on AArch64/Arm64, but 3.7 does.

Also:
* Add CC_Ghc constructor to LlvmCallConvention.
* Replace `maxSupportLlvmVersion`/`minSupportLlvmVersion` with
  a single `supportedLlvmVersion` variable.
* Get `supportedLlvmVersion` from version specified in configure.ac.
* Drop llvmVersion field from DynFlags (no longer needed because only
  one version is supported).

Test Plan: Validate on x86_64 and arm

Reviewers: bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #10953
      29310b62
  3. 06 Oct, 2015 1 commit
    • Edward Z. Yang's avatar
      Deduplicate one-shot/make compile paths. · 427f8a15
      Edward Z. Yang authored 
      Summary:
We had a duplicate copy of the code for --make and for -c
which was a pain.  The call graph looked something like this:

    compileOne -> genericHscCompileGetFrontendResult -> genericHscFrontend
                                   hscCompileOneShot ---^

with genericHscCompileGetFrontendResult and hscCompileOneShot
duplicating logic for deciding whether or not recompilation
was needed.

This patchset fixes it, so now everything goes through this call-chain:

    compileOne (--make entry point)
        Calls hscIncrementCompile, invokes the pipeline to do codegen
        and sets up linkables.
    hscIncrementalCompile (-c entry point)
        Calls hscIncrementalFrontend, and then simplifying,
        desugaring, and writing out the interface.
    hscIncrementalFrontend
        Performs recompilation avoidance, if recompilation needed,
        does parses typechecking.

I also cleaned up some of the MergeBoot nonsense by introducing
a FrontendResult type.

NB: this BREAKS #8101 again, because I can't unconditionally desugar
due to Haddock barfing on lint, see #10600
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, bgamari, simonmar, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1302
      427f8a15
  5. 02 Oct, 2015 1 commit
  7. 21 Sep, 2015 1 commit
    • Edward Z. Yang's avatar
      Unify hsig and hs-boot; add preliminary "hs-boot" merging. · 06d46b1e
      Edward Z. Yang authored 
      This patch drops the file level distinction between hs-boot and hsig;
we figure out which one we are compiling based on whether or not there
is a corresponding hs file lying around.

To make the "import A" syntax continue to work for bare hs-boot
files, we also introduce hs-boot merging, which takes an A.hi-boot
and converts it to an A.hi when there is no A.hs file in scope.
This will be generalized in Backpack to merge multiple A.hi files together;
which means we can jettison the "load multiple interface files" functionality.

This works automatically for --make, but for one-shot compilation
we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o
from a local A.hi-boot file; Backpack will extend this mechanism further.

Has Haddock submodule update to deal with change in msHsFilePath behavior.

    - This commit drops support for the hsig extension. Can
      we support it?  It's annoying because the finder code is
      written with the assumption that where there's an hs-boot
      file, there's always an hs file too.  To support hsig, you'd
      have to probe two locations.  Easier to just not support it.

    - #10333 affects us, modifying an hs-boot still doesn't trigger
      recomp.

    - See compiler/main/Finder.hs: this diff is very skeevy, but
      it seems to work.

    - This code cunningly doesn't drop hs-boot files from the
      "drop hs-boot files" module graph, if they don't have a
      corresponding hs file.  I have no idea if this actually is useful.
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, bgamari, spinda

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1098
      06d46b1e
  9. 05 Aug, 2015 1 commit
  11. 23 Jul, 2015 1 commit
    • spinda's avatar
      Generate .dyn_o files for .hsig files with -dynamic-too · d2b4df15
      spinda authored 
      With -dynamic-too, .dyn_o files were not being generated for .hsig
files.  Normally, this is handled in the pipeline; however, the branch
for .hsig files called compileEmptyStub directly instead of going
through runPipeline.  When compiling a Cabal package that included .hsig
files, this triggered a linker error later on, as it expected a .dyn_o
file to have been generated for each .hsig.

The fix is to use runPipeline for .hsig files, just as with .hs files.
Alternately, one could duplicate the logic for handling -dynamic-too in
the .hsig branch, but simply calling runPipeline ends up being much
cleaner.

Test Plan: validate

Reviewers: austin, ezyang, bgamari, thomie

Reviewed By: ezyang, thomie

Subscribers: thomie

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

GHC Trac Issues: #10660
      d2b4df15
  13. 17 Jul, 2015 1 commit
  15. 10 Jul, 2015 1 commit
  17. 24 Jun, 2015 1 commit
    • Sergei Trofimovich's avatar
      driver: pass '-fPIC' option to all CC invocations · 4d1316a5
      Sergei Trofimovich authored 
      Reported by mitchty:

  When porting ghc to alpine linux (rumors say they build
  all binaries as Position Independent Executables
  to leverage global ASLR) linker issued obscure errors:

Tiny example:
    $ echo 'main = print "hello"' > a.hs
    $ ghc -fforce-recomp a.hs -fPIC -dynamic -optl-pie -o a
        ld: /tmp/ghc2142_0/ghc2142_5.o: relocation R_X86_64_32 against `ZCMain_main_closure'
            can not be used when making a shared object; recompile with -fPIC
        /tmp/ghc2142_0/ghc2142_5.o: error adding symbols: Bad value
        collect2: error: ld returned 1 exit status

There is two entry points in CC driver:
    'runPhase' (CC) and 'mkExtraObj'

'mkExtraObj' does not handle most of 'runPhase's complexity.
Ideally it should.

This patch only adds -fPIC propagation to 'mkExtraObj'.

Please merge to stable branch.
Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      4d1316a5
  19. 06 May, 2015 1 commit
    • Javran Cheng's avatar
      rts: add "-no-rtsopts-suggestions" option · 477f514f
      Javran Cheng authored 
      Depends on D767

Setting this flag prevents RTS from giving RTS suggestions like "Use
`+RTS -Ksize -RTS' to increase it."

According to the comment @rwbarton made in #9579, sometimes "+RTS"
suggestions don't make sense (e.g. when the program is precompiled and
installed through package managers), we can encourage people to
distribute binaries with either "-no-rtsopts-suggestions" or "-rtsopts".

Reviewed By: erikd, austin

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

GHC Trac Issues: #9579
      477f514f
  21. 06 Apr, 2015 1 commit
  23. 31 Mar, 2015 1 commit
  25. 30 Mar, 2015 1 commit
  27. 28 Mar, 2015 1 commit
  29. 27 Mar, 2015 1 commit
    • thomie's avatar
      Rename driver phases C(obj)cpp to C(obj)cplusplus · abde5da4
      thomie authored 
      Before:
Cpp     = Pre-process C
Ccpp    = Compile C++
Cobjcpp = Compile Objective-C++
CmmCpp  = Pre-process Cmm

Quite confusing! This commit renames `Ccpp` to `Ccplusplus`, and
`Cobjcpp` to `Cobjcplusplus`. The two letters `p-p` keep standing for
`pre-processing` throughout the compiler.

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D756
      abde5da4
  31. 09 Mar, 2015 1 commit
  33. 10 Feb, 2015 1 commit
  35. 03 Jan, 2015 2 commits
  37. 03 Dec, 2014 1 commit
  39. 19 Nov, 2014 1 commit
  41. 18 Nov, 2014 1 commit
  43. 30 Oct, 2014 1 commit
  45. 27 Oct, 2014 1 commit
  47. 24 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Implementation of hsig (module signatures), per #9252 · aa479953
      Edward Z. Yang authored 
      Summary:
Module signatures, like hs-boot files, are Haskell modules which omit
value definitions and contain only signatures.  This patchset implements
one particular aspect of module signature, namely compiling them against
a concrete implementation.  It works like this: when we compile an hsig
file, we must be told (via the -sig-of flag) what module this signature
is implementing.  The signature is compiled into an interface file which
reexports precisely the entities mentioned in the signature file.  We also
verify that the interface is compatible with the implementation.

This feature is useful in a few situations:

    1. Like explicit import lists, signatures can be used to reduce
    sensitivity to upstream changes.  However, a signature can be defined
    once and then reused by many modules.

    2. Signatures can be used to quickly check if a new upstream version
    is compatible, by typechecking just the signatures and not the actual
    modules.

    3. A signature can be used to mediate separate modular development,
    where the signature is used as a placeholder for functionality which
    is loaded in later.  (This is only half useful at the moment, since
    typechecking against signatures without implementations is not implemented
    in this patchset.)

Unlike hs-boot files, hsig files impose no performance overhead.

This patchset punts on the type class instances (and type families) problem:
instances simply leak from the implementation to the signature.  You can
explicitly specify what instances you expect to have, and those will be checked,
but you may get more instances than you asked for.  Our eventual plan is
to allow hiding instances, but to consider all transitively reachable instances
when considering overlap and soundness.

ToDo: signature merging: when a module is provided by multiple signatures
for the same base implementation, we should not consider this ambiguous.

ToDo: at the moment, signatures do not constitute use-sites, so if you
write a signature for a deprecated function, you won't get a warning
when you compile the signature.

Future work: The ability to feed in shaping information so that we can take
advantage of more type equalities than might be immediately evident.
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate and new tests

Reviewers: simonpj, simonmar, hvr, austin

Subscribers: simonmar, relrod, ezyang, carter, goldfire

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

GHC Trac Issues: #9252
      aa479953
  49. 20 Oct, 2014 1 commit
  51. 19 Oct, 2014 1 commit
  53. 05 Oct, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Implement `MIN_VERSION_GLASGOW_HASKELL()` macro · 3549c952
      Herbert Valerio Riedel authored 
      This exposes the `cProjectPatchLevel{1,2}` value at the CPP level to
allow it to be used in CPP conditionals. Concretely, GHC 7.10.2.20150623
would result in

  #define __GLASGOW_HASKELL__             710
  #define __GLASGOW_HASKELL_PATCHLEVEL1__ 2
  #define __GLASGOW_HASKELL_PATCHLEVEL2__ 20150623

while GHC 7.10.3 results in

  #define __GLASGOW_HASKELL__             710
  #define __GLASGOW_HASKELL_PATCHLEVEL1__ 3

and finally GHC 7.9.20141009 results in

  #define __GLASGOW_HASKELL__             709
  #define __GLASGOW_HASKELL_PATCHLEVEL1__ 20141009

As it's error-prone to properly express CPP conditionals for testing GHC
multi-component versions, a new macro `MIN_VERSION_GLASGOW_HASKELL()` is
provided (also via the new CPP include file `ghcversion.h`)

Finally, in order to make it easier to define the new CPP macro
`MIN_VERSION_GLASGOW_HASKELL()`, a new default-included
`include/ghcversion.h` is used for the new CPP definitions.

Reviewed By: ekmett, austin, #ghc

Differential Revision: https://phabricator.haskell.org/D66
      3549c952
  55. 02 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename _closure to _static_closure, apply naming consistently. · 35672072
      Edward Z. Yang authored 
      Summary:
In preparation for indirecting all references to closures,
we rename _closure to _static_closure to ensure any old code
will get an undefined symbol error.  In order to reference
a closure foobar_closure (which is now undefined), you should instead
use STATIC_CLOSURE(foobar).  For convenience, a number of these
old identifiers are macro'd.

Across C-- and C (Windows and otherwise), there were differing
conventions on whether or not foobar_closure or &foobar_closure
was the address of the closure.  Now, all foobar_closure references
are addresses, and no & is necessary.

CHARLIKE/INTLIKE were not changed, simply alpha-renamed.

Part of remove HEAP_ALLOCED patch set (#8199)

Depends on D265
Signed-off-by: Edward Z. Yang's avatarEdward Z. Yang <ezyang@mit.edu>

Test Plan: validate

Reviewers: simonmar, austin

Subscribers: simonmar, ezyang, carter, thomie

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

GHC Trac Issues: #8199
      35672072
  57. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored 
      Summary:
This includes pretty much all the changes needed to make `Applicative`
a superclass of `Monad` finally. There's mostly reshuffling in the
interests of avoid orphans and boot files, but luckily we can resolve
all of them, pretty much. The only catch was that
Alternative/MonadPlus also had to go into Prelude to avoid this.

As a result, we must update the hsc2hs and haddock submodules.
Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>

Test Plan: Build things, they might not explode horribly.

Reviewers: hvr, simonmar

Subscribers: simonmar

Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  59. 27 Aug, 2014 1 commit
  61. 10 Aug, 2014 1 commit
  63. 05 Aug, 2014 1 commit
  65. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. · 4bebab25
      Edward Z. Yang authored 
      Summary:
Previously, both Cabal and GHC defined the type PackageId, and we expected
them to be roughly equivalent (but represented differently).  This refactoring
separates these two notions.

A package ID is a user-visible identifier; it's the thing you write in a
Cabal file, e.g. containers-0.9.  The components of this ID are semantically
meaningful, and decompose into a package name and a package vrsion.

A package key is an opaque identifier used by GHC to generate linking symbols.
Presently, it just consists of a package name and a package version, but
pursuant to #9265 we are planning to extend it to record other information.
Within a single executable, it uniquely identifies a package.  It is *not* an
InstalledPackageId, as the choice of a package key affects the ABI of a package
(whereas an InstalledPackageId is computed after compilation.)  Cabal computes
a package key for the package and passes it to GHC using -package-name (now
*extremely* misnamed).

As an added bonus, we don't have to worry about shadowing anymore.

As a follow on, we should introduce -current-package-key having the same role as
-package-name, and deprecate the old flag.  This commit is just renaming.

The haddock submodule needed to be updated.
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, simonmar, hvr, austin

Subscribers: simonmar, relrod, carter

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

Conflicts:
	compiler/main/HscTypes.lhs
	compiler/main/Packages.lhs
	utils/haddock
      4bebab25
  67. 20 Jul, 2014 1 commit
  69. 27 Jun, 2014 2 commits
  71. 26 Jun, 2014 1 commit
  73. 23 Jun, 2014 2 commits