From owner-freebsd-bugs@freebsd.org Tue Nov 19 13:24:11 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5262E1B2B21 for ; Tue, 19 Nov 2019 13:24:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47HRP71XLtz4TXx for ; Tue, 19 Nov 2019 13:24:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 32B871B2B20; Tue, 19 Nov 2019 13:24:11 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 327981B2B1F for ; Tue, 19 Nov 2019 13:24:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47HRP70PNzz4TXv for ; Tue, 19 Nov 2019 13:24:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CB9ACAF16 for ; Tue, 19 Nov 2019 13:24:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAJDOAsM030658 for ; Tue, 19 Nov 2019 13:24:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAJDOA0j030654 for bugs@FreeBSD.org; Tue, 19 Nov 2019 13:24:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Tue, 19 Nov 2019 13:24:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dclarke@blastwave.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? maintainer-feedback? maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 13:24:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242067 --- Comment #4 from Dennis Clarke --- (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.=