Opened 15 months ago

Closed 15 months ago

Last modified 9 months ago

#7589 closed bug (fixed)

LLVM 3.2 Support

Reported by: dterei Owned by: dterei
Priority: normal Milestone:
Component: Compiler (LLVM) Version: 7.7
Keywords: Cc: george.colpitts@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Incorrect result at runtime Difficulty:
Test Case: Blocked By: #7571, #7575
Blocking: Related Tickets:

Description (last modified by dterei)

LLVM 3.2 is out as of mid December. We need to update the backend to support it.

There seems to be a number of new bugs due to the change.

With LLVM 3.1 we get the following testsuite failures:

OVERALL SUMMARY for test run started at Mon Jan 14 21:42:32 PST 2013
    3552 total tests, which gave rise to
   13164 test cases, of which
       0 caused framework failures
   11606 were skipped

    1515 expected passes
      23 had missing libraries
      15 expected failures
       0 unexpected passes
       5 unexpected failures

Unexpected failures:
*  codeGen/should_run        cgrun044 [exit code non-0] (optllvm)
*  concurrent/should_run     367_letnoescape [bad exit code] (optllvm)
*  numeric/should_run        arith005 [bad stdout] (optllvm)
   typecheck/should_compile  tc226 [exit code non-0] (optllvm)
   typecheck/should_compile  tc235 [exit code non-0] (optllvm)

Where the failures marked with '*' are unique to the LLVM backend.

With LLVM 3.2 we get the following:

OVERALL SUMMARY for test run started at Tue Jan 15 16:02:01 PST 2013
    3552 total tests, which gave rise to
   13164 test cases, of which
       0 caused framework failures
   11606 were skipped

    1512 expected passes
      23 had missing libraries
      15 expected failures
       0 unexpected passes
       8 unexpected failures

Unexpected failures:
** codeGen/should_compile    1916 [exit code non-0] (optllvm)
** codeGen/should_run        cgrun028 [exit code non-0] (optllvm)
*  codeGen/should_run        cgrun044 [exit code non-0] (optllvm)
*  concurrent/should_run     367_letnoescape [bad exit code] (optllvm)
*  numeric/should_run        arith005 [bad stdout] (optllvm)
** numeric/should_run        numrun012 [exit code non-0] (optllvm)
   typecheck/should_compile  tc226 [exit code non-0] (optllvm)
   typecheck/should_compile  tc235 [exit code non-0] (optllvm)

Where failures marked with '*' are unique to the LLVM backend and failures marked with '' are unique to LLVM 3.2 relative to 3.1.

I believe bootstrapping with LLVM also fails now. However, that may be due to the change to the new-code-generator, and not of LLVM 3.1 -> 3.2. I'll create a separate ticket for that.

NOTE: These test suite results were all generated on Mac OS X 10.8.

Change History (11)

comment:1 Changed 15 months ago by dterei

  • Component changed from Compiler to Compiler (LLVM)
  • Description modified (diff)
  • Type of failure changed from None/Unknown to Incorrect result at runtime
  • Version changed from 7.6.1 to 7.7

comment:2 Changed 15 months ago by dterei

  • Description modified (diff)

comment:3 Changed 15 months ago by dterei

  • Blocked By 7571, 7575, 7580, 7588 added

comment:4 Changed 15 months ago by dterei

Both cgrun044 and arith005 are now fixed. LLVM 3.1 only has 367_letnoescape as a failure now.

comment:5 Changed 15 months ago by dterei

367 isn't a big problem, its the yield feature recently added for non-allocating loops. LLVM optimizations currently defeat it though.

comment:6 Changed 15 months ago by dterei

So need to test on OSX, but on Linux x64 I get LLVM 3.2 working perfectly. Only failure is 367_letnoescape which fails on all LLVM versions.

comment:7 Changed 15 months ago by dterei

  • Blocked By 7580 removed

comment:8 Changed 15 months ago by dterei

  • Blocked By 7588 removed

comment:9 Changed 15 months ago by dterei

  • Blocked By 7571 removed

comment:10 Changed 15 months ago by dterei

  • Blocked By 7571 added
  • Resolution set to fixed
  • Status changed from new to closed

comment:11 Changed 13 months ago by george.colpitts

  • Cc george.colpitts@… added

Will this fix be in the forthcoming Haskell Platform? It seems this was found in 7.6.1 and 7.7 but it's not clear to me if the fix has been or will be backported to 7.6.3 which I believe will be the basis for the next version of the Haskell Platform. Also Milestone is blank so I wasn't able to use that to answer my question.

Last edited 9 months ago by george.colpitts (previous) (diff)
Note: See TracTickets for help on using tickets.