1. 18 Sep, 2013 1 commit
  2. 13 Sep, 2013 1 commit
    • Iavor S. Diatchki's avatar
      Add support for evaluation of type-level natural numbers. · 1f77a534
      Iavor S. Diatchki authored
      This patch implements some simple evaluation of type-level expressions
      featuring natural numbers.  We can evaluate *concrete* expressions that
      use the built-in type families (+), (*), (^), and (<=?), declared in
      GHC.TypeLits.   We can also do some type inference involving these
      functions.  For example, if we encounter a constraint such as `(2 + x) ~ 5`
      we can infer that `x` must be 3.  Note, however, this is used only to
      resolve unification variables (i.e., as a form of a constraint improvement)
      and not to generate new facts.  This is similar to how functional
      dependencies work in GHC.
      
      The patch adds a new form of coercion, `AxiomRuleCo`, which makes use
      of a new form of axiom called `CoAxiomRule`.  This is the form of evidence
      generate when we solve a constraint, such as `(1 + 2) ~ 3`.
      
      The patch also adds support for built-in type-families, by adding a new
      form of TyCon rhs: `BuiltInSynFamTyCon`.  such built-in type-family
      constructors contain a record with functions that are used by the
      constraint solver to simplify and improve constraints involving the
      built-in function (see `TcInteract`).  The record in defined in `FamInst`.
      
      The type constructors and rules for evaluating the type-level functions
      are in a new module called `TcTypeNats`.
      1f77a534
  3. 09 Sep, 2013 1 commit
    • thoughtpolice's avatar
      Fix optimization of Parser.y.pp · 9f8e9d29
      thoughtpolice authored
      In 9e133b, the build was modified to pass -fcmm-sink to Parser, but
      unfortunately Parser specifies -O0 in its OPTIONS_GHC directive, meaning
      the sinking pass was actually turned off.
      
      HC_OPTS is the last thing passed to the compiler for that source file
      however, so the correct fix is to also move -O0 out into the build
      system as well.
      
      This was uncovered thanks to a build report from Kazu Yamamoto. Thanks
      to Jan Stolarek for eyeballing this bug and finding it.
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      9f8e9d29
  4. 04 Sep, 2013 1 commit
    • thoughtpolice's avatar
      Make sure -fcmm-sink is passed to Parser properly · 9e133b9d
      thoughtpolice authored
      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: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      9e133b9d
  5. 27 Aug, 2013 1 commit
    • parcs's avatar
      UniqSupply: make mkSplitUniqSupply thread-safe · 036910ad
      parcs authored
      unsafeInterleaveIO is used instead of unsafeDupableInterleaveIO because
      a mk_supply thunk that is simultaneously entered by two threads should
      evaluate to the same UniqSupply.
      
      The UniqSupply counter is now incremented atomically using the RTS's
      atomic_inc().
      
      To mitigate the extra overhead of unsafeInterleaveIO in the
      single-threaded compiler, noDuplicate# is changed to exit early when
      n_capabilities == 1.
      036910ad
  6. 02 Aug, 2013 1 commit
  7. 15 May, 2013 1 commit
  8. 07 Apr, 2013 1 commit
  9. 06 Apr, 2013 2 commits
  10. 15 Mar, 2013 1 commit
  11. 11 Mar, 2013 1 commit
  12. 03 Mar, 2013 3 commits
  13. 02 Mar, 2013 1 commit
  14. 01 Mar, 2013 1 commit
  15. 19 Feb, 2013 1 commit
  16. 18 Feb, 2013 1 commit
  17. 17 Feb, 2013 1 commit
  18. 15 Feb, 2013 1 commit
  19. 17 Jan, 2013 1 commit
    • Simon Marlow's avatar
      Tidy up cross-compiling · 109a1e53
      Simon Marlow authored
      We have two cases:
       1. building a cross-compiler
       2. compiling GHC to run on a foreign platform
      
      These two are done with almost the same setup: (1) is the stage 1
      compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.
      
      The only difference between (1) and (2) is that you if you set up the
      build for (1), then it stops before stage 2 and you can 'make install'
      to install stage 1.
      
      Unfortunately, (2) didn't work, and the build system code needed some
      tidying up.
      
      Change to the way the build is set up:
      
      Before
      ------
      
      To build a cross-compiler:
        ./configure --target=<..>
      
      To compile a foreign GHC:
        ./configure --host=<..> --target=<..>
      
      Now
      ---
      
      To build a cross-compiler:
        ./configure --target=<..>
        And set "Stage1Only=YES" in mk/build.mk
      
      To compile a foreign GHC:
        ./configure --target=<..>
      109a1e53
  20. 05 Dec, 2012 1 commit
    • ian@well-typed.com's avatar
      Don't define DYNAMIC when compiling the dyn way · 3fc453af
      ian@well-typed.com authored
      We want to compile the sources only once, and to produce both vanilla
      and dyn object files. This means that the sources can't differ for the
      two ways.
      
      This needed a bit of a kludge to get keepCAFsForGHCi included only in
      the dynamic library.
      3fc453af
  21. 30 Nov, 2012 1 commit
  22. 23 Nov, 2012 1 commit
  23. 12 Nov, 2012 1 commit
    • ian@well-typed.com's avatar
      Replace mkDerivedConstants.c with DeriveConstants.hs · f49271c0
      ian@well-typed.com authored
      DeriveConstants.hs works in a cross-compilation-friendly way. Rather
      than running a C program that prints out the constants, we just compile
      a C file which has the constants are encoded in symbol sizes. We then
      parse the output of 'nm' to find out what the constants are.
      
      Based on work by Gabor Greif <ggreif@gmail.com>.
      f49271c0
  24. 11 Oct, 2012 1 commit
    • Ian Lynagh's avatar
      Fix build on Windows · b921de76
      Ian Lynagh authored
      gcc couldn't find ghc_boot_platform.h. I'm not sure why it worked on
      Linux.
      b921de76
  25. 10 Oct, 2012 2 commits
  26. 17 Sep, 2012 1 commit
  27. 13 Sep, 2012 2 commits
  28. 05 Sep, 2012 1 commit
  29. 07 Aug, 2012 1 commit
  30. 05 Aug, 2012 3 commits
  31. 29 Jun, 2012 2 commits
  32. 04 May, 2012 1 commit