RVM

Four tests in test run "tiny" fail when compiled with -X:aos:initial_compiler=opt -X:aos:enable_recompilation=false

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.9.2
  • Fix Version/s: 2.9.3
  • Component/s: Compiler: Optimizing
  • Labels:
    None
  • Environment:
    prototype-opt Jikes RVM 2.9.2+svn (r14174) using GNU Classpath 0.97.1
  • Number of attachments :
    4

Description

When forced to use the Opt compiler , four tests in test run "tiny" fail: TestInstanceOf, TestFloatingRem, tNewInstance (in "basic"), InvokeReflect (in "opttests"). The former three produce unexpected output, the latter dies with in a unexpected exit code and a lengthy stack trace. (I have attached the TestInstanceOf.default.txt, TestFloatingRem.default.txt, and InvokeReflect.default.txt outputs – for some reasons only three attachments are possible.)

Attachments

  1. Text File
    InvokeReflect.default.txt
    29/Apr/08 3:55 AM
    11 kB
    Andreas Sewe
  2. Text File
    TestFloatingRem.default.txt
    29/Apr/08 3:55 AM
    3 kB
    Andreas Sewe
  3. Text File
    TestInstanceOf.default.txt
    29/Apr/08 3:55 AM
    0.4 kB
    Andreas Sewe
  4. Text File
    tNewInstance.default.txt
    29/Apr/08 5:07 AM
    0.0 kB
    Andreas Sewe

Issue Links

This issue is superceded by:
RVM-467 BURS performing illegal reordering to before PEI Blocker Closed
RVM-468 Instanceof test differs in opt compiler from baseline for instanceof/checkcast of magic[][] Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andreas Sewe added a comment -

I added the fourth and last output file manually via the "Attach File" action.

Show
Andreas Sewe added a comment - I added the fourth and last output file manually via the "Attach File" action.
Hide
Permalink
Ian Rogers added a comment -

One of the bugs (the 1st output) highlights a bug where we're not checking for unsupported uses reachable by moves in the object replacement. This is a bug that we should clear up for 2.9.3. Can you provide more detail on what the other failures are? For example, which part of the files differ, the line in the test, you can also inspect the IR using -X:opt:print_all_ir=true . This will help me find the bugs expediently. Thanks for the report!

Show
Ian Rogers added a comment - One of the bugs (the 1st output) highlights a bug where we're not checking for unsupported uses reachable by moves in the object replacement. This is a bug that we should clear up for 2.9.3. Can you provide more detail on what the other failures are? For example, which part of the files differ, the line in the test, you can also inspect the IR using -X:opt:print_all_ir=true . This will help me find the bugs expediently. Thanks for the report!
Hide
Permalink
Ian Rogers added a comment -

r14176 fixes InvokeReflect. The floating point remainder difference is a 0.0 has become -0.0. The TestInstanceOf difference is that we're different opt and baseline on what exactly can be instanceof and checkcasted for the case of a magic[][]. The tNewInstance difference is that we're failing (but not printing stack traces?) in the tNewInstance test that tries to check we're not allowing privileged calls to constructors.

Show
Ian Rogers added a comment - r14176 fixes InvokeReflect. The floating point remainder difference is a 0.0 has become -0.0. The TestInstanceOf difference is that we're different opt and baseline on what exactly can be instanceof and checkcasted for the case of a magic[][]. The tNewInstance difference is that we're failing (but not printing stack traces?) in the tNewInstance test that tries to check we're not allowing privileged calls to constructors.
Hide
Permalink
Ian Rogers added a comment -

The tNewInstance failure is a big one, what's happening is that the we have 2 calls in a BB, the first should throw an exception, following this there's a flag set operation. BURS is reordering the flag set operation before the call.

Show
Ian Rogers added a comment - The tNewInstance failure is a big one, what's happening is that the we have 2 calls in a BB, the first should throw an exception, following this there's a flag set operation. BURS is reordering the flag set operation before the call.
Hide
Permalink
Andreas Sewe added a comment -

Good, you are able to reproduce all four failed tests. I just had fun a lot of fun with the tNewInstance test, which succeeded or failed depending on where I put my System.out.println's for debugging output (FWIW, all exceptions are thrown and caught as anticipated), but given that you already found the cause of the failure, I will skip sending you lots and lots of IR...

Show
Andreas Sewe added a comment - Good, you are able to reproduce all four failed tests. I just had fun a lot of fun with the tNewInstance test, which succeeded or failed depending on where I put my System.out.println's for debugging output (FWIW, all exceptions are thrown and caught as anticipated), but given that you already found the cause of the failure, I will skip sending you lots and lots of IR...
Hide
Permalink
Ian Rogers added a comment -

r14177 fixes the TestFloatingRem bug.

Show
Ian Rogers added a comment - r14177 fixes the TestFloatingRem bug.
Hide
Permalink
Ian Rogers added a comment -

r14176 and r14177 fix InvokeReflect and TestFloatingRem, the tNewInstance failure requires work on the normal burs dependencies. I can't see a quick fix so have moved the issue to RVM-467. RVM-468 is a reminder to fix the difference in the magic[][] test, which shouldn't be critical.

Show
Ian Rogers added a comment - r14176 and r14177 fix InvokeReflect and TestFloatingRem, the tNewInstance failure requires work on the normal burs dependencies. I can't see a quick fix so have moved the issue to RVM-467. RVM-468 is a reminder to fix the difference in the magic[][] test, which shouldn't be critical.
Hide
Permalink
Ian Rogers added a comment -

Thanks Andreas. The tNewInstance bug (RVM-467) really shouldn't be happening - unsafe reordering of code is bad. Tracking RVM-468 should be straight forward but takes time I haven't got right now. If you could have a look I'd appreciate it. I'd leave RVM-467 for Dave.

Show
Ian Rogers added a comment - Thanks Andreas. The tNewInstance bug (RVM-467) really shouldn't be happening - unsafe reordering of code is bad. Tracking RVM-468 should be straight forward but takes time I haven't got right now. If you could have a look I'd appreciate it. I'd leave RVM-467 for Dave.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.