From owner-freebsd-standards@freebsd.org Sun Apr 23 17:24:53 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A009CD4DCE5 for ; Sun, 23 Apr 2017 17:24:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F30017E9 for ; Sun, 23 Apr 2017 17:24:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3NHOrJ0019189 for ; Sun, 23 Apr 2017 17:24:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 218657] Usage of I (_Complex_I) from complex.h results in unexpected warnings with clang -pedantic Date: Sun, 23 Apr 2017 17:24:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.mimetype 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 17:24:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218657 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #181784|text/x-csrc |text/plain mime type| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Sun Apr 23 18:21:38 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD7D3D4D213 for ; Sun, 23 Apr 2017 18:21:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD415BBB for ; Sun, 23 Apr 2017 18:21:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3NILbBo079266 for ; Sun, 23 Apr 2017 18:21:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 208266] strxfrm and strcoll do not always agree Date: Sun, 23 Apr 2017 18:21:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.mimetype 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 18:21:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208266 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #168579|text/x-csrc |text/plain mime type| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Sun Apr 23 18:21:44 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8063D4D254 for ; Sun, 23 Apr 2017 18:21:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7A85D33 for ; Sun, 23 Apr 2017 18:21:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3NILiRF080494 for ; Sun, 23 Apr 2017 18:21:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 208266] strxfrm and strcoll do not always agree Date: Sun, 23 Apr 2017 18:21:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.mimetype 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 18:21:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208266 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #168580|application/x-shellscript |text/plain mime type| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Sun Apr 23 18:25:45 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE42DD4D6F3 for ; Sun, 23 Apr 2017 18:25:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9DEDD135C for ; Sun, 23 Apr 2017 18:25:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3NIPjvd090663 for ; Sun, 23 Apr 2017 18:25:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 191365] Name demangling doesn't work for local names Date: Sun, 23 Apr 2017 18:25:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 9.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.mimetype 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 18:25:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191365 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #144120|text/x-c++src |text/plain mime type| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Sun Apr 23 18:37:23 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 026B1D4DE88 for ; Sun, 23 Apr 2017 18:37:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5D501D52 for ; Sun, 23 Apr 2017 18:37:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3NIbMke014579 for ; Sun, 23 Apr 2017 18:37:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 189353] POSIX sem_unlink does not actually unlink the semaphore in the process context Date: Sun, 23 Apr 2017 18:37:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.mimetype 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 18:37:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D189353 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #142353|text/x-csrc |text/plain mime type| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Sun Apr 23 18:37:30 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F95BD4DEA1 for ; Sun, 23 Apr 2017 18:37:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6EEB91D7B for ; Sun, 23 Apr 2017 18:37:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3NIbUmn014717 for ; Sun, 23 Apr 2017 18:37:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 189353] POSIX sem_unlink does not actually unlink the semaphore in the process context Date: Sun, 23 Apr 2017 18:37:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.mimetype 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 18:37:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D189353 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #142352|text/x-csrc |text/plain mime type| | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Sun Apr 23 21:00:33 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB207D4DA87 for ; Sun, 23 Apr 2017 21:00:33 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87A811F9B for ; Sun, 23 Apr 2017 21:00:33 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3NL01mj071305 for ; Sun, 23 Apr 2017 21:00:33 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201704232100.v3NL01mj071305@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-standards@FreeBSD.org Subject: Problem reports for freebsd-standards@FreeBSD.org that need special attention Date: Sun, 23 Apr 2017 21:00:33 +0000 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 21:00:33 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 193594 | stddef.h should define max_align_t Open | 191586 | FreeBSD doesn't validate negative edgecases in bi 2 problems total for which you should take action. From owner-freebsd-standards@freebsd.org Mon Apr 24 13:30:35 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2BADD4CE07 for ; Mon, 24 Apr 2017 13:30:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E209D1531 for ; Mon, 24 Apr 2017 13:30:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3ODUZcL057799 for ; Mon, 24 Apr 2017 13:30:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 191365] Name demangling doesn't work for local names Date: Mon, 24 Apr 2017 13:30:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 9.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 13:30:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191365 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Overcome By Events --- Comment #3 from Ed Maste --- Thank you for the report. FreeBSD 9 is now past its end of life date. I have verified that this issue is not present in FreeBSD 10 and later. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Mon Apr 24 13:30:42 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9341BD4CE12 for ; Mon, 24 Apr 2017 13:30:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82F67154D for ; Mon, 24 Apr 2017 13:30:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3ODUgUK057999 for ; Mon, 24 Apr 2017 13:30:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 191365] Name demangling doesn't work for local names Date: Mon, 24 Apr 2017 13:30:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 9.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: emaste@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 13:30:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191365 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-standards@FreeBSD.o |emaste@freebsd.org |rg | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Mon Apr 24 23:55:39 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D117ED4EB18; Mon, 24 Apr 2017 23:55:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E412A4E; Mon, 24 Apr 2017 23:55:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3ONRhmP054815 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Apr 2017 16:27:43 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3ONRhSI054814; Mon, 24 Apr 2017 16:27:43 -0700 (PDT) (envelope-from sgk) Date: Mon, 24 Apr 2017 16:27:43 -0700 From: Steve Kargl To: freebsd-numerics@freebsd.org Cc: freebsd-standards@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170424232743.GA54621@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170413171248.GA86780@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170413171248.GA86780@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 23:55:39 -0000 On Thu, Apr 13, 2017 at 10:12:48AM -0700, Steve Kargl wrote: > On Sun, Apr 09, 2017 at 03:08:09PM -0700, Steve Kargl wrote: > > Both IEEE-754 2008 and ISO/IEC TS 18661-4 define the half-cycle > > trignometric functions cospi, sinpi, and tanpi. The attached > > patch implements cospi[fl], sinpi[fl], and tanpi[fl]. Limited > > testing on the cospi and sinpi reveal a max ULP less than 0.89; > > while tanpi is more problematic with a max ULP less than 2.01 > > in the interval [0,0.5]. The algorithms used in these functions > > are documented in {ks}_cospi.c, {ks}_sinpi.c, and s_tanpi.c. > > > > Note 1. ISO/IEC TS 18661-4 says these funstions are guarded by > > a predefine macro. I have no idea or interest in what clang and > > gcc do with regards to this macro. I've put the functions behind > > __BSD_VISIBLE. > > > > Note 2. I no longer have access to a system with ld128 and > > adequate support to compile and test the ld128 implementations > > of these functions. Given the almost complete lack of input from > > others on improvements to libm, I doubt that anyone cares. If > > someone does care, the ld128 files contain a number of FIXME comments, > > and in particular, while the polynomial coefficients are given > > I did not update the polynomial algorithms to properly use the > > coefficients. > > > > The code is attached the bug reportr. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218514 > > > > While everyone is busy reviewing and testing the patch available > in bugzilla, I suspect some may be wondering about the inverse > half-cycle trignometric functions. I have worked out an algorithm > for asinpi[fl] and have a working implemenation of asinpif(x). > It will take a couple of weeks (due to limited available time) > before I can submit asinpi[fl], acospi[fl], and atanpi[fl], but > work is in progress. > I have what appears to be working versions of asinpi[fl]. It was suggested elsewhere that using an Estrin's method to sum the polynomial approximations instead of Horner's method may allow modern CPUs to better schedule generated code. I have implemented an Estrin's-like method for sinpi[l] and cospi[l], and indeed the generated code is faster on my Intel core2 duo with only a slight degradation in the observed max ULP. I'll post new versions to bugzilla in the near future. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-standards@freebsd.org Tue Apr 25 05:30:44 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C6A0D4F358; Tue, 25 Apr 2017 05:30:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id BB1E81D90; Tue, 25 Apr 2017 05:30:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 40EE142B512; Tue, 25 Apr 2017 15:13:45 +1000 (AEST) Date: Tue, 25 Apr 2017 15:13:44 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: freebsd-numerics@freebsd.org, freebsd-standards@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170424232743.GA54621@troutmask.apl.washington.edu> Message-ID: <20170425143120.R933@besplex.bde.org> References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170413171248.GA86780@troutmask.apl.washington.edu> <20170424232743.GA54621@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=VIhQITioF-Sxmys2TWEA:9 a=s4eJatwz83rb22bD:21 a=v3ws3rOyY_mnV_cf:21 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 05:30:44 -0000 On Mon, 24 Apr 2017, Steve Kargl wrote: > I have what appears to be working versions of asinpi[fl]. It > was suggested elsewhere that using an Estrin's method to > sum the polynomial approximations instead of Horner's method > may allow modern CPUs to better schedule generated code. > I have implemented an Estrin's-like method for sinpi[l] > and cospi[l], and indeed the generated code is faster on > my Intel core2 duo with only a slight degradation in the > observed max ULP. I'll post new versions to bugzilla in > the near future. I didn't remember Estrin, but checked Knuth and see that his method is a subset of what I use routinely. I might have learned it from Knuth. I tried all methods in Knuth, but they didn't seem to be any better at first. Later I learned more about scheduling. Estrin's method now seems routine as a subset of scheduling. You already used it in expl: for ld80: X x2 = x * x; X x4 = x2 * x2; Unlike in Knuth's description of Estrin, we don't try to order the operations to suit the CPU(s) in the code, but just try to keep them independent, as required for them to execute independently. Compilers will rearrange them anyway, sometimes even correctly, but it makes little difference (on OOE CPUs) to throw all of the operations into the pipeline and see how fast something comes out). X q = x4 * (x2 * (x4 * X /* X * XXX the number of terms is no longer good for X * pairwise grouping of all except B3, and the X * grouping is no longer from highest down. X */ X (x2 * B12 + (x * B11 + B10)) + X (x2 * (x * B9 + B8) + (x * B7 + B6))) + X (x * B5 + B4.e)) + x2 * x * B3.e; This is arranged to look a bit like Horner's method at first (operations not written in separate statements), but it is basically Estrin's method with no extensions to more complicated sub-expressions than Estrin's, but complications for accuracy: - I think accuracy for the B3 term is unimportant, but for some reason (perhaps just the one in the comment) it is grouped separately. Estrin might use x3 * (B3.e + x * B4.e). - accuracy is important for B0 through B2 terms, and we don't use Estrin for them. Efficiency is a matter of running the above in parallel with the evaluation of lower terms. The above shouldn't steal any resources from evaluation of the lower terms unless it is the slow part. Normally you want N (2 independent streams to complete at the same time ready for a final addition). The above also does some power-of-2 grouping which has been messed up by changing the number of terms in the polynomial (see the comment). Generally this costs time time of 1 operation for each missed optimization. The above hasn't been rearranged since it is a lot of work to keep rearranging it during development and development stalled after committing it. The ld128 cases has larger problems from this. It has 2 sets of polynomials, both higher order, with sub-optimal numbers of terms. Here is my program for testing the results of quadratic grouping on x86. It shows little qualitative difference between Athlon-XP and Haswell. Haswell is just faster: XX #include XX XX static __inline void XX cpuid(int ax) XX { XX __asm __volatile("cpuid" : "=a" (ax) : "0" (ax) : "cx", "dx", "bx"); XX } XX #define puid(ax) XX XX double P0, P1, P2, P3; XX double P4, P5, P6, P7; XX double P8, P9, Pa, Pb; XX double Pc, Pd, Pe, Pf; XX double Q0, Q1, Q2, Q3; XX double Q4, Q5, Q6, Q7; XX double Q8, Q9, Qa, Qb; XX double Qc, Qd, Qe, Qf; XX volatile double a, r; XX XX #define FREQ 2010168298 /* sysctl -n machdep.tsc_freq */ XX XX #define NITER (FREQ / 10) XX XX int XX main(int argc, char **argv) XX { XX double x; XX int i, n; XX XX n = (argc == 1 ? 0 : atoi(argv[1])); XX switch (n) { XX default: XX for (i = 0; i < NITER; i++) { XX cpuid(0); XX } XX break; XX case 2: XX for (i = 0; i < NITER; i++) { XX x = a; XX r = x*P1+P0; XX cpuid(0); XX } XX break; XX case -4: XX for (i = 0; i < NITER; i++) { XX x = a; XX r = P0+x*(P1+x*(P2+x*P3)); XX cpuid(0); XX } XX break; XX case 4: XX for (i = 0; i < NITER; i++) { XX x = a; XX r = (x*P3+P2)*(x*x)+(x*P1+P0); XX cpuid(0); XX } XX break; XX case 5: XX for (i = 0; i < NITER; i++) { XX x = a; XX double t32 = x*P3+P2; XX double t10 = x*P1+P0; XX double x2 = x*x; XX r = t32*x2+t10; XX cpuid(0); XX } XX break; XX case -8: XX for (i = 0; i < NITER; i++) { XX x = a; XX r = P0+x*(P1+x*(P2+x*(P3+x*(P4+x*(P5+x*(P6+x*P7)))))); XX cpuid(0); XX } XX break; XX case 6: XX for (i = 0; i < NITER; i++) { XX x = a; XX double lo = 0.0; XX r = ((x*P7+P6)*(x*x)+(x*P5+P4))*((x*x)*(x*x)) + XX ((x*P3+P2)*(x*x)+lo); XX cpuid(0); XX } XX break; XX case 7: XX for (i = 0; i < NITER; i++) { XX double d = a; XX double lo = 0.0; XX double t = d*P7+P6; XX double z = d*d; XX double s = d*P5+P4; XX double rl = d*P3+P2; XX #if 0 XX r = lo + z * rl + z * z * s + z * z * (z * t); XX #elif 0 XX r = lo + z * z * (z * t) + z * z * s + z * rl; XX #elif 0 XX r = z * z * (z * t) + (z * z * s + lo) + z * rl; XX #else XX r = z * z * (z * t) + z * z * s + (z * rl + lo); XX #endif XX cpuid(0); XX } XX break; XX case 8: XX for (i = 0; i < NITER; i++) { XX cpuid(0); XX } XX break; XX case 9: XX for (i = 0; i < NITER; i++) { XX x = a; XX double t76 = x*P7+P6; XX double t54 = x*P5+P4; XX double t32 = x*P3+P2; XX double x2 = x*x; XX r = ((t76 )*x2+(t54 ))*(x2*x2) + XX ((t32 )*x2+(x*P1+P0)); XX cpuid(0); XX } XX break; XX case 10: XX for (i = 0; i < NITER; i++) { XX x = a; XX double t76 = x*P7+P6; XX double t32 = x*P3+P2; XX double t54 = x*P5+P4; XX double x2 = x*x; XX r = ((t76 )*x2+(t54 ))*(x2*x2) + XX ((t32 )*x2+(x*P1+P0)); XX cpuid(0); XX } XX break; XX case 11: XX for (i = 0; i < NITER; i++) { XX x = a; XX double t76 = x*P7+P6; XX double t54 = x*P5+P4; XX double t32 = x*P3+P2; XX double x2 = x*x; XX double t7654 = t76*x2+t54; XX double t3210 = t32*x2+(x*P1+P0); XX r = t7654*(x2*x2) + t3210; XX cpuid(0); XX } XX break; XX case -16: XX for (i = 0; i < NITER; i++) { XX x = a; XX r = P0+x*(P1+x*(P2+x*(P3+x*(P4+x*(P5+x*(P6+x*(P7+x*(P8+x*(P9+x*(Pa+x*(Pb+x*(Pc+x*(Pd+x*(Pe+x*(Pf))))))))))))))); XX cpuid(0); XX } XX break; XX case 16: XX for (i = 0; i < NITER; i++) { XX x = a; XX r = (((x*Pf+Pe)*(x*x)+(x*Pd+Pc))*((x*x)*(x*x)) + XX ((x*Pb+Pa)*(x*x)+(x*P9+P8)))* XX (((x*x)*(x*x))*((x*x)*(x*x))) + XX (((x*P7+P6)*(x*x)+(x*P5+P4))*((x*x)*(x*x)) + XX ((x*P3+P2)*(x*x)+(x*P1+P0))); XX cpuid(0); XX } XX break; XX case 17: XX for (i = 0; i < NITER; i++) { XX x = a; XX double tfe = x*Pf+Pe; XX double tba = x*Pb+Pa; XX double t76 = x*P7+P6; XX double t32 = x*P3+P2; XX double x2 = x*x; XX double tdc = x*Pd+Pc; XX double t98 = x*P9+P8; XX double t54 = x*P5+P4; XX r = (((tfe )*x2+(tdc ))*(x2*x2) + XX ((tba )*x2+(t98 )))*((x2*x2)*(x2*x2)) + XX (((t76 )*x2+(t54 ))*(x2*x2) + XX ((t32 )*x2+(x*P1+P0))); XX cpuid(0); XX } XX break; XX case 18: XX for (i = 0; i < NITER; i++) { XX x = a; XX double tfe = x*Pf+Pe; XX double tba = x*Pb+Pa; XX double t76 = x*P7+P6; XX double tdc = x*Pd+Pc; XX double x2 = x*x; XX double t32 = x*P3+P2; XX double t98 = x*P9+P8; XX double t54 = x*P5+P4; XX double t10 = x*P1+P0; XX double x4 = x2*x2; XX double tfedc = x2*tfe+tdc; XX double tba98 = x2*tba+t98; XX double t7654 = x2*t76+t54; XX double t3210 = x2*t32+t10; XX double tfedcba98 = x4*tfedc+tba98; XX double t76543210 = x4*t7654+t3210; XX r = (x4*x4)*tfedcba98+t76543210; XX cpuid(0); XX } XX break; XX case -32: XX for (i = 0; i < NITER; i++) { XX x = a; XX r = P0+x*(P1+x*(P2+x*(P3+x*(P4+x*(P5+x*(P6+x*(P7+x*(P8+x*(P9+x*(Pa+x*(Pb+x*(Pc+x*(Pd+x*(Pe+x*(Pf+x*(Q0+x*(Q1+x*(Q2+x*(Q3+x*(Q4+x*(Q5+x*(Q6+x*(Q7+x*(Q8+x*(Q9+x*(Qa+x*(Qb+x*(Qc+x*(Qd+x*(Qe+x*(Qf))))))))))))))))))))))))))))))); XX cpuid(0); XX } XX break; XX case 32: XX for (i = 0; i < NITER; i++) { XX x = a; XX r = ((((x*Qf+Qe)*(x*x)+(x*Qd+Qc))*((x*x)*(x*x)) + XX ((x*Qb+Qa)*(x*x)+(x*Q9+Q8)))* XX (((x*x)*(x*x))*((x*x)*(x*x))) + XX (((x*Q7+Q6)*(x*x)+(x*Q5+Q4))*((x*x)*(x*x)) + XX ((x*Q3+Q2)*(x*x)+(x*Q1+Q0))))* XX ((((x*x)*(x*x))*((x*x)*(x*x)))* XX (((x*x)*(x*x))*((x*x)*(x*x)))) + XX ((((x*Pf+Pe)*(x*x)+(x*Pd+Pc))*((x*x)*(x*x)) + XX ((x*Pb+Pa)*(x*x)+(x*P9+P8)))* XX (((x*x)*(x*x))*((x*x)*(x*x))) + XX (((x*P7+P6)*(x*x)+(x*P5+P4))*((x*x)*(x*x)) + XX ((x*P3+P2)*(x*x)+(x*P1+P0)))); XX cpuid(0); XX } XX break; XX case 33: XX for (i = 0; i < NITER; i++) { XX x = a; XX double Tfe = x*Qf+Qe; XX double tfe = x*Pf+Pd; XX double T76 = x*Q7+Q6; XX double t76 = x*P7+P6; XX double x2 = x*x; XX r = ((((Tfe )*x2+(x*Qd+Qc))*(x2*x2) + XX ((x*Qb+Qa)*x2+(x*Q9+Q8)))*((x2*x2)*(x2*x2)) + XX (((T76 )*x2+(x*Q5+Q4))*(x2*x2) + XX ((x*Q3+Q2)*x2+(x*Q1+Q0))))*(((x2*x2)*(x2*x2))*((x2*x2)*(x2*x2))) + XX ((((tfe )*x2+(x*Pd+Pc))*(x2*x2) + XX ((x*Pb+Pa)*x2+(x*P9+P8)))*((x2*x2)*(x2*x2)) + XX (((t76 )*x2+(x*P5+P4))*(x2*x2) + XX ((x*P3+P2)*x2+(x*P1+P0)))); XX cpuid(0); XX } XX break; XX } XX return (0); XX } It only tests power-of-2 number of terms. With say 6 or 7 terms, it is harder to run much faster than with 8 terms, but easy to try all other resonable groupings. With 8-15 terms, it is harder to try enough other groupings. It tests using temporary variables to try to get the best order. This makes a little difference with gcc-3.3, less than that with gcc-4.2 and no difference with clang. Looking at the generated code can be instructive. The compiler sometimes finds a good order that you might not think of. Also, you can see where it is constrained by dependencies. Modern x86 (SSE-mumble or AVX-mumble) have the basic Estrin operation of B0 + x * B1 as a single operation (v*fma* in AVX). Basic Estrin would reduce to Horner if this were used. But the C standard doesn't really allow using it, and compilers don't use it on x86. gcc did use it on ia64. It also takes unportable CFLAGS to get high SSE/AVX support, and gives unportable binaries when used. Don't use the libm fma since that tends to be 10-100 times slower than not using it (perhaps only 10 times slower if it claims to be fast). This libm fma is only useful for algorithm development and cases where efficiency doesn't matter. Fma is about half an ulp more accurate than separate operations. Bruce From owner-freebsd-standards@freebsd.org Tue Apr 25 06:36:45 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37F36D4F513; Tue, 25 Apr 2017 06:36:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2199F1D18; Tue, 25 Apr 2017 06:36:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3P6ah72046094 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Apr 2017 23:36:43 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3P6ahPV046093; Mon, 24 Apr 2017 23:36:43 -0700 (PDT) (envelope-from sgk) Date: Mon, 24 Apr 2017 23:36:43 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-numerics@freebsd.org, freebsd-standards@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170425063643.GA45906@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170413171248.GA86780@troutmask.apl.washington.edu> <20170424232743.GA54621@troutmask.apl.washington.edu> <20170425143120.R933@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170425143120.R933@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 06:36:45 -0000 On Tue, Apr 25, 2017 at 03:13:44PM +1000, Bruce Evans wrote: > On Mon, 24 Apr 2017, Steve Kargl wrote: > > > I have what appears to be working versions of asinpi[fl]. It > > was suggested elsewhere that using an Estrin's method to > > sum the polynomial approximations instead of Horner's method > > may allow modern CPUs to better schedule generated code. > > I have implemented an Estrin's-like method for sinpi[l] > > and cospi[l], and indeed the generated code is faster on > > my Intel core2 duo with only a slight degradation in the > > observed max ULP. I'll post new versions to bugzilla in > > the near future. > > I didn't remember Estrin, but checked Knuth and see that his > method is a subset of what I use routinely. I might have learned > it from Knuth. I tried all methods in Knuth, but they didn't seem > to be any better at first. Later I learned more about scheduling. > Estrin's method now seems routine as a subset of scheduling. I think I came across this in Knuth as well, but I may have picked of the name Estrin from Mueller's book (or google :). > > You already used it in expl: for ld80: > I recall that that is your handy work. > X x2 = x * x; > X x4 = x2 * x2; > > Unlike in Knuth's description of Estrin, we don't try to order the > operations to suit the CPU(s) in the code, but just try to keep them > independent, as required for them to execute independently. Compilers > will rearrange them anyway, sometimes even correctly, but it makes > little difference (on OOE CPUs) to throw all of the operations into > the pipeline and see how fast something comes out). > > X q = x4 * (x2 * (x4 * > X /* > X * XXX the number of terms is no longer good for > X * pairwise grouping of all except B3, and the > X * grouping is no longer from highest down. > X */ > X (x2 * B12 + (x * B11 + B10)) + > X (x2 * (x * B9 + B8) + (x * B7 + B6))) + > X (x * B5 + B4.e)) + x2 * x * B3.e; > > This is arranged to look a bit like Horner's method at first (operations > not written in separate statements), but it is basically Estrin's method > with no extensions to more complicated sub-expressions than Estrin's, > but complications for accuracy: > - I think accuracy for the B3 term is unimportant, but for some reason > (perhaps just the one in the comment) it is grouped separately. Estrin > might use x3 * (B3.e + x * B4.e). Yes, it is most likely an accuracy issue. I found something similar with sinpi/cospi. My k_sinpi.c has #if 0 double x2; /* Horner's method. */ x2 = x * x; sm = x2 * (x2 * (x2 * (x2 * (x2 * (x2 * s7 + s6) + s5) + s4) + s3) + s2) + s1; #else double x2, x4; /* Sort of Estrin's method. */ x2 = x * x; x4 = x2 * x2; sm = (s5 + s6 * x2 + s7 * x4) * x4 * x4 + (s2 + s3 * x2 + s4 * x4) * x2 + s1; #endif The addition of s1 must occur last, or I get greater 1 ULP for a number of values. My timing show on Intel core2 duo /* Horner's methods. */ laptop-kargl:kargl[219] ./testd -S -s -m 0 -M 0.25 -n 22 sinpi time: 0.066 usec per call cospi time: 0.063 usec per call /* Estrin's methods. */ laptop-kargl:kargl[212] ./testd -S -s -m 0 -M 0.25 -n 22 sinpi time: 0.059 usec per call cospi time: 0.055 usec per call Here, -n 22 means to test 2**22 - 1 values in the interval [0,0.25]. For the older functions that were committed a few years ago, I should probably go back to recheck timings and accuracy with and without Estrin's method. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-standards@freebsd.org Tue Apr 25 08:28:08 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9E72D4EB9C; Tue, 25 Apr 2017 08:28:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 4040C1C43; Tue, 25 Apr 2017 08:28:07 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id B19C0104877B; Tue, 25 Apr 2017 18:27:57 +1000 (AEST) Date: Tue, 25 Apr 2017 18:27:52 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: freebsd-numerics@freebsd.org, freebsd-standards@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170425063643.GA45906@troutmask.apl.washington.edu> Message-ID: <20170425173542.S1401@besplex.bde.org> References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170413171248.GA86780@troutmask.apl.washington.edu> <20170424232743.GA54621@troutmask.apl.washington.edu> <20170425143120.R933@besplex.bde.org> <20170425063643.GA45906@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=pMMk53J5QUvvM_BoBYoA:9 a=JWkNqyrBzBJkAUbv:21 a=d3hanlBOIU_nJgXb:21 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 08:28:08 -0000 On Mon, 24 Apr 2017, Steve Kargl wrote: > On Tue, Apr 25, 2017 at 03:13:44PM +1000, Bruce Evans wrote: >> [for expl] >> This is arranged to look a bit like Horner's method at first (operations >> not written in separate statements), but it is basically Estrin's method >> with no extensions to more complicated sub-expressions than Estrin's, >> but complications for accuracy: >> - I think accuracy for the B3 term is unimportant, but for some reason >> (perhaps just the one in the comment) it is grouped separately. Estrin >> might use x3 * (B3.e + x * B4.e). > > Yes, it is most likely an accuracy issue. I found something > similar with sinpi/cospi. My k_sinpi.c has > > #if 0 > double x2; > /* Horner's method. */ > x2 = x * x; > sm = x2 * (x2 * (x2 * (x2 * (x2 * (x2 * s7 + s6) + s5) + s4) + s3) > + s2) + s1; Horner's of course has about as many dependencies as operations (13), so on modern x86 this is limited by the latency of 3-5 cycles/instructions or 39-65 cycles. Multiplications take an extra cycle in more cases, so it is better to have more additions, but unfortunately Horner gives 1 more multuplication. With no dependencies, the limit would be throughput -- 2 instructions/cycle of 6.5 cycles rounded up to 7; then add latency for the last operation to get about 11. With practical dependencies, it is hard to get more than a 2-fold speedup. > #else > double x2, x4; > /* Sort of Estrin's method. */ > x2 = x * x; > x4 = x2 * x2; > sm = (s5 + s6 * x2 + s7 * x4) * x4 * x4 > + (s2 + s3 * x2 + s4 * x4) * x2 + s1; > #endif This looks OK. The only obvious improvement is to try grouping x4*x4 so that it can be evaluated separately. This reduces the length of dependency chains by 1, but increases early pressure on multiplication. Don't write this as x8 = x4*x4. Compilers will do the equivalent. You can also replace x4 by (x2*x2) but there are many x4's so this might be less readable. > The addition of s1 must occur last, or I get greater 1 ULP > for a number of values. Indeed. This prevents using the best order, which is the opposite. You used the best order for the other inner terms, but not so obviously for the first outer addition. However, the compiler is free to reorder that: consider: T2 + T1 + T0 T2 is more complicated and everything depends on it, so should be started first, but possibly T1 can be started first because it is simpler. Here it is not significantly simpler. However, for: T3 + T2 + T1 + T0 the natural left-to-right grouping is usually pessimial. This should be written as: T3 + (T2 + T1) + T0 Unfortunately, we can't write this naturally and usually optimally as: T0 + T1 + T2 + T3 due to the accuracy problem with T0. Maybe right this as: T1 + T2 + T3 + T0 // only T0 in unnatural order For expl, I tried all orders. > My timing show on Intel core2 duo > > /* Horner's methods. */ > laptop-kargl:kargl[219] ./testd -S -s -m 0 -M 0.25 -n 22 > sinpi time: 0.066 usec per call > cospi time: 0.063 usec per call > > /* Estrin's methods. */ > laptop-kargl:kargl[212] ./testd -S -s -m 0 -M 0.25 -n 22 > sinpi time: 0.059 usec per call > cospi time: 0.055 usec per call > > Here, -n 22 means to test 2**22 - 1 values in the interval > [0,0.25]. The improvement is marginal. Only worth doing if it doesn't complicate the code much. Older CPUs can't exploit te parallelism so well, so I would expect a relatively larger improvement. Don't measure in usec, since they are hard to scale. 0.66 usec and 1.86 GHz is more than 100 cycles. This is quite slow. I get similar times for cos and sin on an older Athlon-XP (~40 in float prec, ~160 in double and ~270 in long double). Newer CPUs are about 4 times faster in double prec (only 2 times fast in float prec) in cycles despite having similar nominal timing, by unclogging their pipes. We should also try to use the expression A*x + B more often so that things with be faster when this is done by fma, but this happens naturally anyway. Bruce From owner-freebsd-standards@freebsd.org Wed Apr 26 03:23:58 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FE8CD50FC3; Wed, 26 Apr 2017 03:23:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B09C9C; Wed, 26 Apr 2017 03:23:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3Q3No8O087663 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Apr 2017 20:23:50 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3Q3NoEL087662; Tue, 25 Apr 2017 20:23:50 -0700 (PDT) (envelope-from sgk) Date: Tue, 25 Apr 2017 20:23:50 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-numerics@freebsd.org, freebsd-standards@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170426032350.GA87524@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170413171248.GA86780@troutmask.apl.washington.edu> <20170424232743.GA54621@troutmask.apl.washington.edu> <20170425143120.R933@besplex.bde.org> <20170425063643.GA45906@troutmask.apl.washington.edu> <20170425173542.S1401@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170425173542.S1401@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 03:23:58 -0000 On Tue, Apr 25, 2017 at 06:27:52PM +1000, Bruce Evans wrote: > On Mon, 24 Apr 2017, Steve Kargl wrote: > > > On Tue, Apr 25, 2017 at 03:13:44PM +1000, Bruce Evans wrote: > > >> [for expl] > >> This is arranged to look a bit like Horner's method at first (operations > >> not written in separate statements), but it is basically Estrin's method > >> with no extensions to more complicated sub-expressions than Estrin's, > >> but complications for accuracy: > >> - I think accuracy for the B3 term is unimportant, but for some reason > >> (perhaps just the one in the comment) it is grouped separately. Estrin > >> might use x3 * (B3.e + x * B4.e). > > > > Yes, it is most likely an accuracy issue. I found something > > similar with sinpi/cospi. My k_sinpi.c has > > > > #if 0 > > double x2; > > /* Horner's method. */ > > x2 = x * x; > > sm = x2 * (x2 * (x2 * (x2 * (x2 * (x2 * s7 + s6) + s5) + s4) + s3) > > + s2) + s1; > > Horner's of course has about as many dependencies as operations (13), so > on modern x86 this is limited by the latency of 3-5 cycles/instructions > or 39-65 cycles. Multiplications take an extra cycle in more cases, so > it is better to have more additions, but unfortunately Horner gives 1 > more multuplication. > > With no dependencies, the limit would be throughput -- 2 instructions/cycle > of 6.5 cycles rounded up to 7; then add latency for the last operation to > get about 11. > > With practical dependencies, it is hard to get more than a 2-fold speedup. > > > #else > > double x2, x4; > > /* Sort of Estrin's method. */ > > x2 = x * x; > > x4 = x2 * x2; > > sm = (s5 + s6 * x2 + s7 * x4) * x4 * x4 > > + (s2 + s3 * x2 + s4 * x4) * x2 + s1; > > #endif > > This looks OK. The only obvious improvement is to try grouping x4*x4 > so that it can be evaluated separately. This reduces the length of > dependency chains by 1, but increases early pressure on multiplication. > Don't write this as x8 = x4*x4. Compilers will do the equivalent. > You can also replace x4 by (x2*x2) but there are many x4's so this > might be less readable. The grouping of (x4*x4) and (x2 * x4) in other polynomials indeed give small improvements. I've reworked the approximations in sinpi[l], cospi[l], and tanpi[l]. I did not see any improves with the float versions as the order of the polynomials are fairly small (order of 4). > > The addition of s1 must occur last, or I get greater 1 ULP > > for a number of values. > > Indeed. This prevents using the best order, which is the opposite. > You used the best order for the other inner terms, but not so obviously > for the first outer addition. However, the compiler is free to reorder > that: consider: > > T2 + T1 + T0 > > T2 is more complicated and everything depends on it, so should be started > first, but possibly T1 can be started first because it is simpler. Here > it is not significantly simpler. However, for: > > T3 + T2 + T1 + T0 > > the natural left-to-right grouping is usually pessimial. This should be > written as: > > T3 + (T2 + T1) + T0 > > Unfortunately, we can't write this naturally and usually optimally as: > > T0 + T1 + T2 + T3 > > due to the accuracy problem with T0. Maybe right this as: > > T1 + T2 + T3 + T0 // only T0 in unnatural order > > For expl, I tried all orders. I tried a few different orders; particularly with the long double functions. I also managed to break the code a few times. Thankfully, I have everything in a subversion repository. > > > My timing show on Intel core2 duo > > > > /* Horner's methods. */ > > laptop-kargl:kargl[219] ./testd -S -s -m 0 -M 0.25 -n 22 > > sinpi time: 0.066 usec per call > > cospi time: 0.063 usec per call > > > > /* Estrin's methods. */ > > laptop-kargl:kargl[212] ./testd -S -s -m 0 -M 0.25 -n 22 > > sinpi time: 0.059 usec per call > > cospi time: 0.055 usec per call > > > > Here, -n 22 means to test 2**22 - 1 values in the interval > > [0,0.25]. > > The improvement is marginal. Only worth doing if it doesn't complicate > the code much. Older CPUs can't exploit te parallelism so well, so I > would expect a relatively larger improvement. Don't measure in usec, > since they are hard to scale. 0.66 usec and 1.86 GHz is more than 100 > cycles. This is quite slow. I get similar times for cos and sin on an > older Athlon-XP (~40 in float prec, ~160 in double and ~270 in long > double). Newer CPUs are about 4 times faster in double prec (only 2 > times fast in float prec) in cycles despite having similar nominal > timing, by unclogging their pipes. I'm assuming your 0.66 in the above is a typo as I wrote 0.066. I also got some improvement by changing the splitting of a few entities into high and low parts by a simple cast. Instead of doing EXTRACT_WORDS(hx, lx, x); INSERT_WORDS(xhi, hx, 0); xlo = x - xhi; I do xhi = (float)x; xlo = x - xhi; but this seems to only help in some situation. My new timing for x in [0,0.25] on my 1995.05 MHz Core2 duo gives Horner sinpi time: 0.073 usec per call (~146 cycles) cospi time: 0.070 usec per call (~140) tanpi time: 0.112 usec per call (~224) Estrin sinpi time: 0.064 usec per call (~128) cospi time: 0.060 usec per call (~120) tanpi time: 0.088 usec per call (~176) tanpi benefits the most as it has an order 16 polynomial, which allows some freedom in group terms. I don't think I can do much better. For example, the approximation for sinpi(x) is sinpi(x) = x * (s0 + x2 * S(x2)) where S(x2) is the polynomial and I need to split x2 into high and low parts and s0 is split. The kernel with the Estrin method and with the polynomial coefficients is static inline double __kernel_sinpi(double x) { double hi, lo, sm, xhi, xlo; uint32_t hx, lx; double x2, x4; /* Sort of Estrin's method. */ x2 = x * x; x4 = x2 * x2; sm = (s5 + s6 * x2 + s7 * x4) * (x4 * x4) + (s2 + s3 * x2 + s4 * x4) * x2 + s1; EXTRACT_WORDS(hx, lx, x); INSERT_WORDS(xhi, hx, 0); xlo = x - xhi; lo = xlo * (x + xhi) * sm; hi = xhi * xhi * sm; lo = x * lo + xlo * (s0hi + s0lo) + x * hi; return (lo + xhi * s0lo + xhi * s0hi); } The order of terms in the last 5 lines matters. Testing yields a = 2.4220192246482908e-01, /* 0x3fcf0078, 0xfc01e3f0 */ sinpi(a) = 6.8957335930938313e-01, /* 0x3fe610fc, 0x264da72e */ sin(pi*a) = 6.8957335930938324e-01, /* 0x3fe610fc, 0x264da72f */ ULP: 0.79950446 MAX ULP: 0.79950446 Total tested: 8388606 1.0 < ULP : 0 0.9 < ULP <= 1.0: 0 0.8 < ULP <= 0.9: 0 0.7 < ULP <= 0.8: 554 0.6 < ULP <= 0.7: 11275 > We should also try to use the expression A*x + B more often so that > things with be faster when this is done by fma, but this happens > naturally anyway. Using A*x+B or B+A*x did not seem to matter. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-standards@freebsd.org Thu Apr 27 23:08:22 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9359BD534C3 for ; Thu, 27 Apr 2017 23:08:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 829571E7D for ; Thu, 27 Apr 2017 23:08:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3RN8MGc077427 for ; Thu, 27 Apr 2017 23:08:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 218514] [LIBM] implementations of sinpi[fl], cospi[fl], and tanpi[fl] Date: Thu, 27 Apr 2017 23:08:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sgk@troutmask.apl.washington.edu X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 23:08:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218514 --- Comment #1 from sgk@troutmask.apl.washington.edu --- Created attachment 182139 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D182139&action= =3Dedit New patch with updated algorithms The attach patch supersedes the previously submitted patch. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Fri Apr 28 03:47:09 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77663D54AEF for ; Fri, 28 Apr 2017 03:47:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6689C187A for ; Fri, 28 Apr 2017 03:47:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3S3l9d1014756 for ; Fri, 28 Apr 2017 03:47:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 207918] C++ ostream operator << broken for unsigned long long when using showbase with octal format Date: Fri, 28 Apr 2017 03:47:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: dwmcrobb@me.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 03:47:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207918 --- Comment #5 from Daniel McRobb --- It's been a year and some of my library unit tests continue to fail due to = this bug. Can we get the patch committed so I don't have to keep applying it on= our machines? Do I need to change the Component in the bug? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Fri Apr 28 14:32:35 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28986D5366A for ; Fri, 28 Apr 2017 14:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17CE76BD for ; Fri, 28 Apr 2017 14:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3SEWYYm037035 for ; Fri, 28 Apr 2017 14:32:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 207918] C++ ostream operator << broken for unsigned long long when using showbase with octal format Date: Fri, 28 Apr 2017 14:32:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: bsdports@kyle-evans.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 14:32:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207918 Kyle Evans changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bsdports@kyle-evans.net, | |dim@FreeBSD.org --- Comment #6 from Kyle Evans --- Hi, CC'ing dim@ on this -- he's committed some libc++ bits, might be able to provide you with some direction. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Fri Apr 28 18:25:02 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3444D536D5 for ; Fri, 28 Apr 2017 18:25:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 927001EC for ; Fri, 28 Apr 2017 18:25:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3SIP2P1085329 for ; Fri, 28 Apr 2017 18:25:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 207918] C++ ostream operator << broken for unsigned long long when using showbase with octal format Date: Fri, 28 Apr 2017 18:25:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: dwmcrobb@me.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 18:25:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207918 --- Comment #7 from Daniel McRobb --- Thanks Kyle, I appreciate it! --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Sat Apr 29 10:54:30 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AB06D55B84 for ; Sat, 29 Apr 2017 10:54:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39D371D31 for ; Sat, 29 Apr 2017 10:54:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3TAsTbs044403 for ; Sat, 29 Apr 2017 10:54:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 207918] C++ ostream operator << broken for unsigned long long when using showbase with octal format Date: Sat, 29 Apr 2017 10:54:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 10:54:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207918 --- Comment #8 from Dimitry Andric --- I'm looking at the problem now. I still don't fully understand how this co= de operates, as my attempts at debugging it have failed until now. In any cas= e, it is definitely a bug, but before applying any patches, I would rather lik= e to discuss it with upstream. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-standards@freebsd.org Sat Apr 29 14:18:25 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C050ED55526 for ; Sat, 29 Apr 2017 14:18:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A465A1CA for ; Sat, 29 Apr 2017 14:18:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3TEIOIW096464 for ; Sat, 29 Apr 2017 14:18:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 207918] C++ ostream operator << broken for unsigned long long when using showbase with octal format Date: Sat, 29 Apr 2017 14:18:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: 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-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 14:18:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207918 --- Comment #9 from Dimitry Andric --- I have submitted an upstream review here: https://reviews.llvm.org/D32670 --=20 You are receiving this mail because: You are the assignee for the bug.=