Stream: git-wasmtime

Topic: wasmtime / issue #4512 cranelift: fma_f32 tests fail on G...

view this post on Zulip Wasmtime GitHub notifications bot (Jul 22 2022 at 19:22):

alexcrichton opened issue #4512:

I was testing out using the windows-latest image with Nick's stack walking PR because I think that should fix a longstanding blocker for updating the CI image.

In doing so though I get:

FAIL filetests\filetests\runtests\fma.clif: interpret
Caused by:
    Failed test: run: %fma_f32(0x1.060000p7, 0x1.340488p7, 0x1.310e42p4) == 0x1.3b88e6p14, actual: 0x1.3b88e8p14

I'm not sure what that corresponds to in the test itself but I suspect that there's just a difference between the old fma symbol on Windows and the new.

cc @afonso360

view this post on Zulip Wasmtime GitHub notifications bot (Jul 23 2022 at 12:47):

afonso360 commented on issue #4512:

This is interesting.

I tried to make a CI run of fma.clif alone and it did pass the tests. (This is based on the main branch from yesterday).

I briefly read the stack walking changes, but I don't see any compile flags or other build changes that would explain this difference.

I pulled your fast-stack-walking2 branch and ran it again on CI. It fails only on windows-latest x86_64-pc-windows-gnu but not on windows-latest. But I don't understand why it works on main, and not with fast-stack-walking2 applied.

Note:

I also had some issues building the cmake examples on windows-latest
Which don't seem to trigger on the stack walking branch (possibly due to #4369 ?) I haven't investigated this too far.

I can file an issue for this if you think it's relevant.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 23 2022 at 14:00):

afonso360 edited a comment on issue #4512:

This is interesting.

I tried to make a CI run of fma.clif alone and it did pass the tests. (This is based on the main branch from yesterday).

I briefly read the stack walking changes, but I don't see any compile flags or other build changes that would explain this difference.

I pulled your fast-stack-walking2 branch and ran it again on CI. It fails only on windows-latest x86_64-pc-windows-gnu but not on windows-latest. But I don't understand why it works on main, and not with fast-stack-walking2 applied.

Edit: This is not true, I accidentally deleted the CARGO_BUILD_TARGET env var in the original run. So the only difference is that this fails in windows-latest x86_64-pc-windows-gnu instead of windows-latest. Both on main and fast-stack-walking2

Note:

I also had some issues building the cmake examples on windows-latest
Which don't seem to trigger on the stack walking branch (possibly due to #4369 ?) I haven't investigated this too far.

I can file an issue for this if you think it's relevant.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 23 2022 at 14:12):

afonso360 edited a comment on issue #4512:

This is interesting.

I tried to make a CI run of fma.clif alone and it did pass the tests. (This is based on the main branch from yesterday).

I briefly read the stack walking changes, but I don't see any compile flags or other build changes that would explain this difference.

I pulled your fast-stack-walking2 branch and ran it again on CI. It fails only on windows-latest x86_64-pc-windows-gnu but not on windows-latest. But I don't understand why it works on main, and not with fast-stack-walking2 applied.

Edit: This is not true, I accidentally deleted the CARGO_BUILD_TARGET env var in the original run. So the only difference is that this fails in windows-latest x86_64-pc-windows-gnu instead of windows-latest. Both on main and fast-stack-walking2

Note:

I also had some issues building the cmake examples on windows-latest
Which don't seem to trigger on the stack walking branch (possibly due to #4369 ?) I haven't investigated this too far.

I can file an issue for this if you think it's relevant.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 23 2022 at 15:24):

afonso360 commented on issue #4512:

I suspect this is related to fma/fmaf bugs on MinGW-w64.

See: https://sourceforge.net/p/mingw-w64/bugs/848/

I compiled the test case in that bug report, with the additional inputs that we are seeing in the interpreter and it also failed.

It does not fail that test case on windows-2019, however it fails some others that we don't have in our test suite.

It looks like fma/fmaf is buggy in MinGW. That bug report has been open for 2 years. What should we do here? I really don't want to polyfill fma, should we grab it from some other library?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 23 2022 at 15:25):

afonso360 edited a comment on issue #4512:

I suspect this is related to fma/fmaf bugs on MinGW-w64.

See: https://sourceforge.net/p/mingw-w64/bugs/848/

I compiled the test case in that bug report, with the additional inputs that we are seeing in the interpreter and it also failed. (Called Testcase[6] on the output)

It does not fail that test case on windows-2019, however it fails some others that we don't have in our test suite.

It looks like fma/fmaf is buggy in MinGW. That bug report has been open for 2 years. What should we do here? I really don't want to polyfill fma, should we grab it from some other library?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 23 2022 at 15:29):

afonso360 edited a comment on issue #4512:

I suspect this is related to fma/fmaf bugs on MinGW-w64.

See: https://sourceforge.net/p/mingw-w64/bugs/848/

I compiled the test case in that bug report, with the additional inputs that we are seeing in the interpreter and it also failed. (Called Testcase[6] on the output)

It does not fail that test case on windows-2019, however it fails some others that we don't have in our test suite.

It looks like fma/fmaf is buggy in MinGW. That bug report has been open for 2 years. What should we do here? Grab a polyfill from some other library?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 23 2022 at 17:26):

afonso360 edited a comment on issue #4512:

I suspect this is related to fma/fmaf bugs on MinGW-w64.

See: https://sourceforge.net/p/mingw-w64/bugs/848/

I compiled the test case in that bug report, with the additional inputs that we are seeing in the interpreter and it also failed. (Called Testcase[6] on the output)

It does not fail that test case on windows-2019, however it fails some others that we don't have in our test suite.

It looks like fma/fmaf is buggy in MinGW. That bug report has been open for 2 years. What should we do here? Grab a polyfill from some other library?

Edit: We can trigger this on the current CI, see: #4517

view this post on Zulip Wasmtime GitHub notifications bot (Jul 25 2022 at 19:09):

TheGreatRambler commented on issue #4512:

I also had some issues building the cmake examples on windows-latest
That is because cmake --target for tests is not consistent between compilers. --target test works for gcc, mingw, macos. --target RUN_TESTS works for msvc, really dumb platform difference. It looks like you already know updating should fix it.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 25 2022 at 19:09):

TheGreatRambler edited a comment on issue #4512:

I also had some issues building the cmake examples on windows-latest

That is because cmake --target for tests is not consistent between compilers. --target test works for gcc, mingw, macos. --target RUN_TESTS works for msvc, really dumb platform difference. It looks like you already know updating should fix it.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 06 2022 at 03:19):

alexcrichton commented on issue #4512:

This has since been resolved so I think this is good to close.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 06 2022 at 03:19):

alexcrichton closed issue #4512:

I was testing out using the windows-latest image with Nick's stack walking PR because I think that should fix a longstanding blocker for updating the CI image.

In doing so though I get:

FAIL filetests\filetests\runtests\fma.clif: interpret
Caused by:
    Failed test: run: %fma_f32(0x1.060000p7, 0x1.340488p7, 0x1.310e42p4) == 0x1.3b88e6p14, actual: 0x1.3b88e8p14

I'm not sure what that corresponds to in the test itself but I suspect that there's just a difference between the old fma symbol on Windows and the new.

cc @afonso360

Last updated: Nov 22 2024 at 17:03 UTC