1. 10 Nov, 2005 2 commits
  2. 07 Nov, 2005 1 commit
  3. 13 Dec, 2004 1 commit
  4. 18 Nov, 2004 1 commit
    • ross's avatar
      [project @ 2004-11-18 11:23:11 by ross] · ac6c88ab
      ross authored
      Hugs only: these all exhaust Hugs's heap, so make life_space_leak an
      expected failure (CAF leak), and skip andre_monad, barton-mangler-bug
      and jules_xref.
  5. 17 Nov, 2004 1 commit
    • ross's avatar
      [project @ 2004-11-17 18:40:40 by ross] · 40d3234f
      ross authored
      GHC-only tests:
      	signals002	uses Handlers
      	forkprocess01	forkProcess
      	timeexts001	tests obsolete library
      	net002		non-blocking I/O
      	thurston-modular-arith	GHC-only scoped type variables
  6. 12 Nov, 2004 1 commit
  7. 09 Nov, 2004 1 commit
  8. 06 Nov, 2004 1 commit
  9. 06 Oct, 2004 1 commit
  10. 09 Sep, 2004 1 commit
  11. 10 Mar, 2004 1 commit
  12. 24 Sep, 2003 1 commit
  13. 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
      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.
  14. 23 May, 2003 2 commits
    • simonmar's avatar
      [project @ 2003-05-23 14:20:35 by simonmar] · 709feb3b
      simonmar authored
      This test is an expected failure, but its original purpose seems to
      have been lost along the way somewhere.
      It is indeed failing, but I susepct not for the same reasons that it
      was originally failing.  After fixing a few compilation errors I
      managed to get it to run, whereupon it fails with "Prelude.read: no
      parse", which may or may not be the correct result.  As far as I can
      tell, this test never worked.  In the previous incarnation of the test
      suite, it was even disabled.
    • simonmar's avatar
      [project @ 2003-05-23 13:43:47 by simonmar] · c6eaad0b
      simonmar authored
      Reclassify these test failures as "expected failures".  We are now at
      ZBB (zero bug bounce).
  15. 02 Dec, 2002 1 commit
  16. 19 Nov, 2002 2 commits
  17. 19 Aug, 2002 1 commit
  18. 01 Aug, 2002 4 commits
  19. 31 Jul, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-07-31 14:24:18 by simonmar] · e5063a04
      simonmar authored
      Revamp the testsuite framework.  The previous framework was an
      experiment that got a little out of control - a whole new language
      with an interpreter written in Haskell was rather heavyweight and left
      us with a maintenance problem.
      So the new test driver is written in Python.  The downside is that you
      need Python to run the testsuite, but we don't think that's too big a
      problem since it only affects developers and Python installs pretty
      easily onto everything these days.
        - 790 lines of Python, vs. 5300 lines of Haskell + 720 lines of
          <strange made-up language>.
        - the framework supports running tests in various "ways", which should
          catch more bugs.  By default, each test is run in three ways:
          normal, -O, and -O -fasm.  Additionally, if profiling libraries
          have been built, another way (-O -prof -auto-all) is added.  I plan
          to also add a 'GHCi' way.
          Running tests multiple ways has already shown up some new bugs!
        - documentation is in the README file and is somewhat improved.
        - the framework is rather less GHC-specific, and could without much
          difficulty be coaxed into using other compilers.  Most of the
          GHC-specificness is in a separate configuration file (config/ghc).
      Things may need a while to settle down.  Expect some unexpected
  20. 28 Mar, 2002 2 commits
  21. 07 Jan, 2002 1 commit
  22. 23 Sep, 2001 2 commits
    • ken's avatar
      [project @ 2001-09-23 21:50:17 by ken] · cccad52b
      ken authored
      Skip the test on alpha-dec-osf3, where we
      run into an infinite loop on some builds
    • ken's avatar
      [project @ 2001-09-23 20:54:39 by ken] · 5bd6235b
      ken authored
      On alpha-dec-osf3, we need to compile galois_raytrace with -O to
      prevent the following fatality:
      ghc-5.02: panic! (the `impossible' happened, GHC version 5.02):
      	Oversize heap check detected.  Please try compiling with -O.
  23. 13 Sep, 2001 1 commit
  24. 07 Sep, 2001 2 commits
  25. 27 Aug, 2001 2 commits
  26. 22 Aug, 2001 5 commits