Date: Tue, 19 Nov 2019 13:24:10 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 242067] libc: r354823 riscv64 has a fault in printf() where IEEE754-2008 fp128 data is output wrong Message-ID: <bug-242067-227-zYvhSCtqVP@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-242067-227@https.bugs.freebsd.org/bugzilla/> References: <bug-242067-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242067 --- Comment #4 from Dennis Clarke <dclarke@blastwave.org> --- (In reply to Kubilay Kocak from comment #3) The output should be the valid IEEE754-2008 floating point representation for pi exactly the same as the Solaris 10 sparcv9 server does :=20 ( 1 ) expected output should be in the last lines : b8 01 17 c5 8c 89 69 84 d1 42 44 b5 1f 92 00 40 pi may be 3.1415926535897932384626433832795028e+00 That would be precisely correct for a little endian RISC-V architecture.=20 ( 2 ) actual output is very correct in memory and very wrong printf behavior :=20 b8 01 17 c5 8c 89 69 84 d1 42 44 b5 1f 92 00 40=20 pi may be 2.0000076405016834831430856216761921e+00 #=20 So I don't think that pi is that close to 2.00000764... :) The other question is have I ever seen this work ? The answer is no. Sadly I have never seen this work correctly.=20 The output here suggests that the printf() routine correctly handles the static format string seen in the assembly listing at LC46 in that we do get the correct number of ascii digits in the correct places however the in memory little endian fp128 data is not handled well. The text [1]"Handbook of Floating-Point Arithmetic", 2nd Ed, pg48, by Muller, J.-M., Brunie, N., de Dinechin, F., Jeannerod, C.-P., Joldes, M., Lef=C3=A8vre, V., Melquiond, G., Revol, N., Torres, S. states that the 128 bit floating point format should have a single sign bit, a set of 15 exponent bits and then a mantissa or significand of 112 bits wherein there is an implied leading "1" bit for an effective 113 bit significand. The IEEE 754-1985 standard did not define this format=20 whereas the [2]IEEE 754-2008 standard does. This is well implemented in Solaris and OpenSolaris as well as on IBM Power9 systems running Red Hat Enterprise Linux.=20 I have single stepped through the relevant lines of the code on an IBM Power system and I think the issue is with /lib/libc/stdio/vfprintf.c where the in memory data is handled wrongly.=20 I have a theory on why we are seeing a value near 2.0 but have to work on that yet. [1] https://www.springer.com/gp/book/9783319765259 [2] IEEE Computer Society. IEEE Standard for Floating-Point Arithmetic. IEEE Standard 754-2008, August 2008. also ISBN: 978-0-7381-5752-8=20 https://ieeexplore.ieee.org/document/4610935 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-242067-227-zYvhSCtqVP>