From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53221 invoked by alias); 21 Jan 2019 23:48:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 52979 invoked by uid 89); 21 Jan 2019 23:48:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=designed X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 21 Jan 2019 23:48:21 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1gljIW-0007TF-89 from joseph_myers@mentor.com ; Mon, 21 Jan 2019 15:48:08 -0800 Received: from digraph.polyomino.org.uk (137.202.0.90) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 21 Jan 2019 23:48:04 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.90_1) (envelope-from ) id 1gljIS-0000Cq-59; Mon, 21 Jan 2019 23:48:04 +0000 Date: Mon, 21 Jan 2019 23:48:00 -0000 From: Joseph Myers To: "H.J. Lu" CC: , Uros Bizjak Subject: Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp In-Reply-To: <20190121161546.2900-1-hjl.tools@gmail.com> Message-ID: References: <20190121161546.2900-1-hjl.tools@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2019-01/txt/msg01251.txt.bz2 On Mon, 21 Jan 2019, H.J. Lu wrote: > TI->SF and TI->DF conversions in libgcc2.c: > > FSTYPE > FUNC (DWtype u) > { > ... > } > > have no rounding mode support. We should replace __floattisf, __floattidf, > __floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp. Please explain what you mean by "have no rounding mode support" (i.e., the exact flow through a function that is incorrect in a non-default rounding mode). This patch is missing testcases - which of course should be architecture-independent. (Any bug in libgcc2.c should first have an architecture-independent fix - it can't be considered fixed based on a fix for one architecture. Then, if some other approach is optimal on particular architectures, they can get optimized variants.) I believe all those function implementations are designed so that only a single rounding occurs, which is for the final result, so no explicit handling of rounding modes is ever needed (the integer code before then may set up sticky bits appropriately to ensure the floating-point parts of the code only need a single rounding, which works in all modes), but maybe there are bugs in certain cases. To identify the correct fix, we need details of the exact code path being used (the exact values of the various macros, choices for the various conditional parts of the function, values each variable has at each point) and where the existing, rounding-mode-independent logic goes wrong. -- Joseph S. Myers joseph@codesourcery.com