1. 13 Oct, 2009 1 commit
  2. 30 Sep, 2009 1 commit
  3. 11 Sep, 2009 1 commit
  4. 21 Aug, 2009 1 commit
  5. 19 Aug, 2009 1 commit
  6. 24 Jul, 2009 1 commit
  7. 09 May, 2009 1 commit
  8. 20 Jan, 2009 1 commit
  9. 12 Nov, 2008 1 commit
  10. 14 Jun, 2008 1 commit
  11. 03 Jun, 2008 1 commit
  12. 29 Feb, 2008 1 commit
  13. 28 Feb, 2008 1 commit
  14. 20 Feb, 2008 1 commit
  15. 06 Feb, 2008 1 commit
    • Simon Marlow's avatar
      Find compiler version-specific output files automatically · 3bc99c34
      Simon Marlow authored
      Also, clean up the way we find the output file. From the comment:
      
      # Finding the sample output.  The filename is of the form
      #
      #   <test>.stdout[-<compiler>][-<version>][-<wordsize>][-<platform>]
      #
      # and we pick the most specific version available.  The <version> is
      # the major version of the compiler (e.g. 6.8.2 would be "6.8").  For
      # more fine-grained control use if_compiler_lt().
      
      I'll update the wiki too.
      3bc99c34
  16. 26 Sep, 2007 1 commit
  17. 18 Jul, 2007 1 commit
  18. 27 Jun, 2007 1 commit
  19. 13 Jun, 2007 1 commit
  20. 25 May, 2007 1 commit
  21. 13 Apr, 2007 1 commit
  22. 05 Mar, 2007 1 commit
  23. 09 Feb, 2007 1 commit
  24. 23 Jan, 2007 1 commit
  25. 18 Sep, 2006 1 commit
  26. 25 Oct, 2006 1 commit
  27. 25 Aug, 2006 1 commit
  28. 10 Feb, 2006 1 commit
  29. 09 Jan, 2006 1 commit
  30. 24 Oct, 2005 1 commit
  31. 14 Mar, 2005 1 commit
  32. 09 Dec, 2004 1 commit
  33. 01 Mar, 2004 1 commit
  34. 19 Aug, 2003 1 commit
    • krc's avatar
      [project @ 2003-08-19 21:51:53 by krc] · a27b1e51
      krc authored
      Added support for testing generation and compilation of External Core
      code. There are two new ways, which are not automatically enabled but can be
      invoked from the command line: extcore and optextcore. Invoking either way will
      test that ghc is able to generate External Core code for a given test, read the
      code back in, and compile it to an executable that produces the expected output
      for the test.
      
      The External Core facility has a few limitations which result in certain tests
      failing for the "extcore" way.
        - External Core can't represent foreign calls other than static C calls
        - External Core can't correctly represent literals resulting from a
          "foreign label" declaration
        - External Core can't represent declarations of datatypes with no
          constructors
      The first of these was already known, and GHC panics if you tried to
      generate External Core for a program containing such a call. The second two
      cases were not handled properly before now; in another commit, I've changed the
      code that emits External Core to panic if either of them arises. Previously,
      GHC would happily generate External Core in either case, but would not be able
      to compile the resulting code.
      
      There are several tests that exhibit these limitations of External Core, so
      they've had to be made "expected failures" when compiling in the extcore or
      optextcore ways.
      a27b1e51
  35. 05 Dec, 2002 1 commit
  36. 04 Dec, 2002 1 commit
  37. 02 Dec, 2002 2 commits
  38. 11 Sep, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-09-11 10:47:57 by simonmar] · f2600f8b
      simonmar authored
      - Move some of the way-selection logic into the configuration file;
        the build system now just passes in variables saying whether the
        compiler supports profiling and native code generation, and the
        configuration file adds the appropriate ways.
      
      - Add a new option to the test driver, --way=<way> to select just a
        single way.
      f2600f8b
  39. 26 Aug, 2002 1 commit