Seems like only 3 fail are related to big-endian, you don't need to worry about other fails.
FAIL: gcc.c-torture/execute/string-opt-5.c FAIL: gcc.target/riscv/shift-and-1.c scan-assembler-not andi FAIL: gcc.target/riscv/shift-and-2.c scan-assembler-not andi On Tue, Feb 23, 2021 at 10:38 AM Kito Cheng <kito.ch...@gmail.com> wrote: > > Hi Marcus: > > Thanks for the quick update, I am testing your V2 patch now, the result seems > really great now, some of fail case seems like not cause by > big-endian patch, I am reviewing and comparing the fail case with the > little-endian build. > > > Should I make a PR against riscv-newlib on GitHub, or would you prefer > > some other process for dealing with newlib fixes related to these > > patches? > > Could you send to newlib mailing list directly, ideally riscv-newlib > just a buffer > we don't want to hold any patch there as possible. > https://sourceware.org/mailman/listinfo/newlib/ > > > > > On Sun, Feb 21, 2021 at 8:17 AM Marcus Comstedt <mar...@mc.pp.se> wrote: > > > > This is an update to the patch series for big endian RISC-V support. > > > > Changes since last version: > > > > * Added documentation of -mbig-endian and -mlittle-endian > > > > * New patch: Fix soft-fp endianness setting > > > > * New patch: Fix trampoline generation on big endian > > > > * New patch: Update the shift-shift-5.c testcase to work correctly > > on big endian > > > > With these changes, and two fixes to newlib (setting correct floating > > point byteorder, and an update to the handcoded assembler for strcmp), > > I'm now down to > > > > ========= Summary of gcc testsuite ========= > > | # of unexpected case / # of unique unexpected > > case > > | gcc | g++ | gfortran | > > rv64gc/ lp64/ medlow | 14 / 8 | 39 / 10 | - | > > > > and of these only two failures do not also occur for little endian: > > > > FAIL: gcc.target/riscv/shift-and-1.c scan-assembler-not andi > > FAIL: gcc.target/riscv/shift-and-2.c scan-assembler-not andi > > > > I'm quite puzzled why these two testcases give different results with > > -mbig-endian compared to with -mlittle-endian though, since they only > > deal with register-to-register operations so the memory model should be > > completely irrelevant... > > > > > > // Marcus > > > > > >
