Hi,
Hi,
Sorry for the late reply.
> And testtools bridgetest itself
Yes, bridgetest_javaserver is the first one that need to be fix.
Can can be argued that it's 1 (there's --without-java as a workaround), but yeah, it's important.
(If NaN was ignored for now it's definitely 1)
I agree for sc_ucalc_formula2s priority here.
> Who says it's just performance?
https://bugs.documentfoundation.org/show_bug.cgi?id=152943#c7:
> "but Calc heavily [...] relies on NaN payload propagation in all math operators."
> Calc without Math is a problem.
I misused English word 'performance', my apologize. I mean that when using LibreOffice Calc with GUI on riscv64, the error code showed correctly. It seems that the lack of NaN payload does not affect the error code at least in GUI mode. So I am quite confused which part does NaN payload affect. And that is why I think it is not urgent to fix '[CUT] sc_ucalc_formula2', because the failed tests 'sc_ucalc_formula2' it are all related to error code mismatch.
Besides, the only failed test in '[CUT] sal_rtl' is also 'test_payloadNaN'.
But I still think that one is bad. I mean, upstream doesn't say
in the issue for no reason that stuff all of the place relies on
that feature, do they?
I am aware that the NaN issue is not easy to fix given it has stuff not in the architecture... Which complicates things.
And then one would need hardware to have this....
But these two test cases are key tests that should not be ignored.
Indeed. (testtools and est_payloadNaN) :)
With
those both fixed libreoffice tests on riscv64 in Debian would
succeed.
Regards,
Rene