https://bugs.kde.org/show_bug.cgi?id=468575
--- Comment #55 from Mark Wielaard <m...@klomp.org> --- On a pioneer box with fedora 38, glibc-2.37-5.fc38.riscv64, GCC 14.2.0, Binutils 2.43.1, GDB 15.1 and all above patches applied: == 743 tests, 3 stderr failures, 4 stdout failures, 0 stderrB failures, 1 stdoutB failure, 0 post failures == gdbserver_tests/hgtls (stdoutB) memcheck/tests/linux/stack_changes (stderr) memcheck/tests/sh-mem-random (stdout) memcheck/tests/sh-mem-random (stderr) none/tests/nestedfns (stdout) none/tests/nestedfns (stderr) none/tests/riscv64/float32 (stdout) none/tests/riscv64/float64 (stdout) hgtls isn't clear, it seems to quit early: +A debugging session is active. + Inferior 1 [Remote target] will be detached. +Quit anyway? (y or n) [answered Y; input not from terminal] +Detaching from program: /home/milkv/valgrind/none/tests/tls, Remote target +Ending remote debugging. +[Inferior 1 (Remote target) detached] stackchange sees a lot of: +Invalid write of size 8 + ... + by 0x........: hello (stack_changes.c:20) + Address 0x........ is on thread 1's stack + in frame #0, created by __vfprintf_internal (???:) This might just be the really old glibc? sh-mem-random gives: +sh-mem-random: can't mmap hi-mem The earlier mappings do seem to work. nestedfns fails with: +Process terminating with default action of signal 11 (SIGSEGV) + Bad permissions for mapped region at address 0x........ + at 0x........: ??? + by 0x........: call_func (nestedfns.c:14) + by 0x........: test1 (nestedfns.c:23) + by 0x........: main (nestedfns.c:37) + Not sure this simply means (noexecstack) nested functions simply don't work on riscv? --- float32.stdout.exp 2024-12-15 21:41:34.723691375 +0100 +++ float32.stdout.out 2024-12-15 22:18:50.073700974 +0100 @@ -882,7 +882,7 @@ output: fa0=0xffffffff00000000, fcsr=0x00000000 fmin.s fa0, fa1, fa2 :: inputs: fa1=0xffffffff00000000, fa2=0xffffffff7fa00000, fcsr=0x00000000 - output: fa0=0xffffffff00000000, fcsr=0x00000010 + output: fa0=0xffffffff7fc00000, fcsr=0x00000010 fmax.s fa0, fa1, fa2 :: inputs: fa1=0xffffffff00000000, fa2=0xffffffff3f800000, fcsr=0x00000000 output: fa0=0xffffffff3f800000, fcsr=0x00000000 @@ -900,7 +900,7 @@ output: fa0=0xffffffff00000000, fcsr=0x00000000 fmax.s fa0, fa1, fa2 :: inputs: fa1=0xffffffff00000000, fa2=0xffffffff7fa00000, fcsr=0x00000000 - output: fa0=0xffffffff00000000, fcsr=0x00000010 + output: fa0=0xffffffff7fc00000, fcsr=0x00000010 fcvt.w.s a0, fa0 :: inputs: fa0=0xffffffff00000000, fcsr=0x00000000 output: a0=0x0000000000000000, fcsr=0x00000000 --- float32.stdout.exp 2024-12-15 21:41:34.723691375 +0100 +++ float32.stdout.out 2024-12-15 22:18:50.073700974 +0100 @@ -882,7 +882,7 @@ output: fa0=0xffffffff00000000, fcsr=0x00000000 fmin.s fa0, fa1, fa2 :: inputs: fa1=0xffffffff00000000, fa2=0xffffffff7fa00000, fcsr=0x00000000 - output: fa0=0xffffffff00000000, fcsr=0x00000010 + output: fa0=0xffffffff7fc00000, fcsr=0x00000010 fmax.s fa0, fa1, fa2 :: inputs: fa1=0xffffffff00000000, fa2=0xffffffff3f800000, fcsr=0x00000000 output: fa0=0xffffffff3f800000, fcsr=0x00000000 @@ -900,7 +900,7 @@ output: fa0=0xffffffff00000000, fcsr=0x00000000 fmax.s fa0, fa1, fa2 :: inputs: fa1=0xffffffff00000000, fa2=0xffffffff7fa00000, fcsr=0x00000000 - output: fa0=0xffffffff00000000, fcsr=0x00000010 + output: fa0=0xffffffff7fc00000, fcsr=0x00000010 fcvt.w.s a0, fa0 :: inputs: fa0=0xffffffff00000000, fcsr=0x00000000 output: a0=0x0000000000000000, fcsr=0x00000000 Oddly this output does match the running float32 and float64 natively. So maybe this cpu has a buggy fmin and fmax instruction? processor : 0 hart : 2 isa : rv64imafdcv mmu : sv39 mvendorid : 0x5b7 marchid : 0x0 mimpid : 0x0 -- You are receiving this mail because: You are watching all bug changes.
