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

RVM

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

Created: 29/Apr/08 03:55 AM Updated: 29/Apr/08 12:17 PM

Component/s:

Compiler: Optimizing

Affects Version/s:

2.9.2

Fix Version/s:

2.9.3

Time Tracking:

Not Specified

File Attachments:

InvokeReflect.default.txt (11 kB)
2.

TestFloatingRem.default.txt (3 kB)
3.

TestInstanceOf.default.txt (0.4 kB)
4.

tNewInstance.default.txt (0.0 kB)

Environment:

« Hide

prototype-opt Jikes RVM 2.9.2+svn (r14174) using GNU Classpath 0.97.1

Issue Links:

Supercedes

This issue is superceded by:

~~RVM-467~~ BURS performing illegal reordering to before PEI

~~RVM-468~~ Instanceof test differs in opt compiler from baseline for instanceof/checkcast of magic[][]

Description

« Hide

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.)

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Andreas Sewe added a comment - 29/Apr/08 05:07 AM

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

[ Permlink | « Hide ]

Ian Rogers added a comment - 29/Apr/08 09:40 AM

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!

[ Permlink | « Hide ]

Ian Rogers added a comment - 29/Apr/08 10:22 AM

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.

[ Permlink | « Hide ]

Ian Rogers added a comment - 29/Apr/08 10:57 AM

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.

[ Permlink | « Hide ]

Andreas Sewe added a comment - 29/Apr/08 11:30 AM

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...

[ Permlink | « Hide ]

Ian Rogers added a comment - 29/Apr/08 11:43 AM

r14177 fixes the TestFloatingRem bug.

[ Permlink | « Hide ]

Ian Rogers added a comment - 29/Apr/08 11:49 AM

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.

[ Permlink | « Hide ]

Ian Rogers added a comment - 29/Apr/08 12:17 PM

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.