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

Re: The current status of LibreOffice testing cases on riscv64



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

 

## 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.

 

## Tests related to UI

 

-[UIT] inputLine

-[UIT] writer_tests4

-[UIT] writer_tests

-[UIT] writer_tests7

 

The previous tests are failed when testing in sequence. They fail at very beginning because soffice.bin does not even start.

 

Here is one of the test log: https://gist.github.com/Sakura286/5c8af63638d139526203cddbd8781412

 

However, testing them separately and they are all success.

 

-[CUT] sw_uiwriter5

 

It failed due to testTdf149498. Since GDB is okay now, further debugging is available.

 

Here is some information about testTdf149498:

 

https://gerrit.libreoffice.org/c/core/+/154708

https://bugs.documentfoundation.org/show_bug.cgi?id=149498

 

## 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 and might be unfeasible.

 

Although IEEE754 ‘recommend’ NaN payload, mainstream architectures implement this feature. To be frank, it is a defect of RISC-V. I am willing to put some efforts on this bug. However I cannot figure out how to fix this at present. - -

 

From,

 

Sakura286.

 


Reply to: