[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The current status of LibreOffice testing cases on riscv64



Hi,

Am 26.01.24 um 11:45 schrieb CHEN Xuan:

Greetings,

 

I’ll share some progress below.

 

## Java Bridge and Higher Bits Cleaning

 

With patch https://gerrit.libreoffice.org/c/core/+/160970, the following tests are fixed.

 

- [JUT] forms_unoapi_1

- [JUT] forms_unoapi_2

- [JUT] forms_unoapi_3

- [JUT] forms_unoapi_4

- [CUT] smoketest

- [UIT] cui_dialogs

 

Jup, will be in the next upload :)


## GDB Debugging Issue

 

It is caused by gcc compilation parameter `--gsplit-dwarf`. This functionality has been broken on riscv64 till now. The solution is disable split debug for LibreOffice -- passing `--disable-split-debug` to autogen.sh.

Added that to CONFIGURE_FLAGS in Debians  packages for riscv64 just in case.

[...]

## Tests related to NaN Payload

 

- [CUT] sc_ucalc_formula2

- [CUT] sal_rtl

 

LibreOffice propagates formula error code with the significant bits in quiet NaN floating points number. Due to lacking of NaN payload support, some of the formula error result is wrongly returned in `#NUM!`(503). The best solution might be add a runtime check of NaN payload(because NaN payload is alternative in IEEE754 and RISC-V spec, compilation time check cannot guarantee that this functionality works well at runtime.) when Calc starts, and switch to non NaN payload mode if the platform does not support it. This solution need to be discussed

but sounds sensible. Can you propose that upstream in https://bugs.documentfoundation.org/show_bug.cgi?id=152943?

I don't think that a "non NaN payload mode" doesn't even exist but maybe you could persade upstream to do that? :)

and might be unfeasible.

 

Maybe. But worth trying.

Although IEEE754 ‘recommend’ NaN payload, mainstream architectures implement this feature. To be frank, it is a defect of RISC-V.

I agree.


Regards,


Rene


Reply to: