1. 25 Jun, 2011 1 commit
    • Ian Lynagh's avatar
      Fix gcc 4.6 warnings; fixes #5176 · 0a6f26f6
      Ian Lynagh authored
      Based on a patch from David Terei.
      
      Some parts are a little ugly (e.g. defining things that only ASSERTs
      use only when DEBUG is defined), so we might want to tweak things a
      little.
      
      I've also turned off -Werror for didn't-inline warnings, as we now
      get a few such warnings.
      0a6f26f6
  2. 22 Jun, 2011 1 commit
  3. 12 Jun, 2011 1 commit
  4. 05 May, 2011 2 commits
  5. 29 Apr, 2011 2 commits
  6. 23 Apr, 2011 7 commits
  7. 22 Apr, 2011 2 commits
  8. 12 Apr, 2011 1 commit
    • Simon Marlow's avatar
      Change the way module initialisation is done (#3252, #4417) · a52ff761
      Simon Marlow authored
      Previously the code generator generated small code fragments labelled
      with __stginit_M for each module M, and these performed whatever
      initialisation was necessary for that module and recursively invoked
      the initialisation functions for imported modules.  This appraoch had
      drawbacks:
      
       - FFI users had to call hs_add_root() to ensure the correct
         initialisation routines were called.  This is a non-standard,
         and ugly, API.
      
       - unless we were using -split-objs, the __stginit dependencies would
         entail linking the whole transitive closure of modules imported,
         whether they were actually used or not.  In an extreme case (#4387,
         #4417), a module from GHC might be imported for use in Template
         Haskell or an annotation, and that would force the whole of GHC to
         be needlessly linked into the final executable.
      
      So now instead we do our initialisation with C functions marked with
      __attribute__((constructor)), which are automatically invoked at
      program startup time (or DSO load-time).  The C initialisers are
      emitted into the stub.c file.  This means that every time we compile
      with -prof or -hpc, we now get a stub file, but thanks to #3687 that
      is now invisible to the user.
      
      There are some refactorings in the RTS (particularly for HPC) to
      handle the fact that initialisers now get run earlier than they did
      before.
      
      The __stginit symbols are still generated, and the hs_add_root()
      function still exists (but does nothing), for backwards compatibility.
      a52ff761
  9. 11 Apr, 2011 1 commit
  10. 08 Apr, 2011 1 commit
  11. 04 Apr, 2011 1 commit
  12. 26 Mar, 2011 1 commit
  13. 23 Mar, 2011 1 commit
  14. 25 Feb, 2011 1 commit
  15. 19 Feb, 2011 1 commit
  16. 10 Feb, 2011 1 commit
  17. 24 Jan, 2011 1 commit
  18. 13 Jan, 2011 1 commit
  19. 16 Jan, 2011 1 commit
  20. 15 Jan, 2011 1 commit
    • Ian Lynagh's avatar
      Build system improvements · a3be88fd
      Ian Lynagh authored
      We no longer use dummy-ghc; instead we don't configure most packages
      until the stage1 compiler is available.
        
      We also now use Cabal for building the ghc-bin package.
      
      There are a couple more sanity checks too.
      a3be88fd
  21. 31 Dec, 2010 1 commit
  22. 19 Dec, 2010 1 commit
    • kili's avatar
      Drop GhcWithLlvmCodeGen configuration bits · 17ff3689
      kili authored
      The LLVM code generator is always built unconditionally, so both the
      configuration variable in mk/config.mk.in as well as the string in
      compilerInfo can be removed.
      17ff3689
  23. 17 Dec, 2010 1 commit
  24. 14 Dec, 2010 2 commits
  25. 07 Dec, 2010 1 commit
    • Ian Lynagh's avatar
      Make CPPFLAGS variables, as well as CFLAGS and LDFLAGS · 75cd9c50
      Ian Lynagh authored
      This fixes the "does unsetenv return void" test in the unix package on
      OS X, if I tell it to make 10.4-compatible binaries. The test uses
      CPPFLAGS but not CFLAGS, so it thought it returned int (as it was
      in 10.5-mode), but the C compiler (using CFLAGS, so in 10.4 mode)
      thought it returned void.
      
      I also added CONF_LD_OPTS_STAGE$3 to the list of things in LDFLAGS,
      which looks like an accidental ommission.
      75cd9c50
  26. 27 Nov, 2010 1 commit
  27. 24 Nov, 2010 3 commits
  28. 23 Nov, 2010 1 commit