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
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 themain
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 onwindows-latest x86_64-pc-windows-gnu
but not onwindows-latest
. But I don't understand why it works onmain
, and not withfast-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.
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 themain
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 onwindows-latest x86_64-pc-windows-gnu
but not onwindows-latest
. But I don't understand why it works onmain
, and not withfast-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 inwindows-latest
x86_64-pc-windows-gnu instead ofwindows-latest
. Both onmain
andfast-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.
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 themain
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 onwindows-latest x86_64-pc-windows-gnu
but not onwindows-latest
. But I don't understand why it works onmain
, and not withfast-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 inwindows-latest x86_64-pc-windows-gnu
instead ofwindows-latest
. Both onmain
andfast-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.
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?
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?
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?
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
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.
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.
alexcrichton commented on issue #4512:
This has since been resolved so I think this is good to close.
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: Dec 23 2024 at 12:05 UTC