Project

General

Profile

Bug #14464

MJIT & MinGW / gcc 7.3.0 seemed ok as of 62337, fail or skip after

Added by MSP-Greg (Greg L) 10 days ago. Updated about 15 hours ago.

Status:
Assigned
Priority:
Normal
Target version:
-
ruby -v:
ruby 2.6.0dev (2018-02-11 trunk 62371) [x64-mingw32]
[ruby-core:85500]

Description

First of all, a thank you to those working on MJIT.

At least three builds of ruby-loco MinGW passed the MJIT tests (62327, 62331, 62337), but after that, the tests have either failed or skipped. First fail was at 62341.

The most recent build (2018-02-11 trunk 62371), skipped with no timeout error in jit_supported? I haven't looked at patching test_jit.rb to see if I can get more info.

I don't know if this is a MinGW issue or a gcc 7.3.0 issue, but, given that it did work for a few builds, I would appreciate it if someone could look into it. Anything I can help with, I'm happy to.

Thanks, Greg

TestJIT_info_62380.txt (33.4 KB) TestJIT_info_62380.txt MSP-Greg (Greg L), 02/12/2018 05:12 AM

History

#1 [ruby-core:85504] Updated by k0kubun (Takashi Kokubun) 10 days ago

It seems that all JIT compilations on MinGW started to fail from r62340, and I fixed it on r62376. Now the tests won't be skipped on MinGW builds. For now, I recommend to specify environment variable RUBY_FORCE_TEST_JIT=1 when running test-all.

After r62376, JIT infrastructure seems working. But some tests in test_jit.rb is failing. The test failure seems to be caused by pointing to invalid address in generated code. As Linux builds with gcc 7.2 are perfectly working, probably it's caused by difference between size of variable types and wrong casting. This was NOT working as of r62337 too. We need deeper investigation for it...

#2 [ruby-core:85505] Updated by MSP-Greg (Greg L) 10 days ago

k0kubun,

Thank you for the response. A few notes:

The test-all log for 62337 showed the two MJIT tests passing, but subsequent builds skipped (or failed with RUBY_FORCE_TEST_JIT).

In the 62375 build (after my first post), both tests skipped.

RubyCI.org is rather 'tablet unfriendly', which biases me away from all use (gotta get over that), but I'll keep an eye on the Linux/gcc 7.2+ builds for the tests results.

Since ruby-loco is used for CI, I won't force fails with RUBY_FORCE_TEST_JIT, so I'll keep checking the logs...

We need deeper investigation for it...

As stated prev, not being a c type, I'm not much help. If there is anything I can add to the build to help identify the issue, I'll be happy to.

NOTE: I just saw 62376 (thanks), the next scheduled build is done at Noon JST. I'll post back when done...

Thanks again, Greg

#3 [ruby-core:85506] Updated by MSP-Greg (Greg L) 10 days ago

k0kubun (Takashi Kokubun),

Appveyor run of 62377 had the following (added backticks for web view):

Retrying...
[1/2]      8 TestJIT#test_compile_insns = 11.33 s = F
[2/2]      7 TestJIT#test_jit_output = 5.58 s = .

  1) Failure:
TestJIT#test_compile_insns [C:/projects/ruby-loco/src/ruby/test/ruby/test_jit.rb:30]:
Failed to run script with JIT:
'``
def foo(&b)
  a = b
  b = 2
  a.call + 2
end

print foo { 1 }

'``


stdout:
'``

'``


stderr:
'``
JIT success (1318.5ms): foo@-e:1 -> C:/Users/appveyor/AppData/Local/temp/_ruby_mjit_p12476u0.c
-e:2:in `foo': wrong argument type Binding (expected Class) (TypeError)
    from -e:7:in `<main>'
Successful MJIT finish

'``

.
<true> expected but was
<false>.

I ran the test locally, and I'm wondering what is using the /Users/user name/AppData/Local/temp folder, as on my system, all TEMP/TMP env variables are set to different folders. I've built ruby for quite a while, and also MSYS2 packages, and I don't ever recall anything using that. For many windows users, their user name may have a space (as mine does). That hasn't been an issue with config files, --user-install gems, etc.

But, when I ran the tests, it mangles the path...

The test-all summary for TestJIT is attached for 62380. I believe there are 9 failures & 5 skips in 64 tests?

Thanks again,

Greg

#4 [ruby-core:85718] Updated by hsbt (Hiroshi SHIBATA) about 15 hours ago

  • Assignee set to k0kubun (Takashi Kokubun)
  • Status changed from Open to Assigned

Also available in: Atom PDF