From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19408 invoked by alias); 22 Jan 2019 02:03:22 -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 12227 invoked by uid 89); 22 Jan 2019 02:03:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= 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; Tue, 22 Jan 2019 02:03:14 +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 1gllPD-0002mI-Jp from joseph_myers@mentor.com ; Mon, 21 Jan 2019 18:03:11 -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; Tue, 22 Jan 2019 02:03:07 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.90_1) (envelope-from ) id 1gllP9-000261-DJ; Tue, 22 Jan 2019 02:03:07 +0000 Date: Tue, 22 Jan 2019 02:03:00 -0000 From: Joseph Myers To: "H.J. Lu" CC: Terry Guo , gcc-patches , Uros Bizjak Subject: Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp In-Reply-To: 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/msg01258.txt.bz2 On Mon, 21 Jan 2019, H.J. Lu wrote: > The testcase at > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931 > > with -frounding-math. __floattisf and __floattidf from libgcc2.c give > the wrong results for FE_UPWARD and FE_TOWARDZERO. I suggest writing a test that looks something like gcc.dg/torture/fp-int-convert-float128-timode-3.c - one that verifies the conversion of a single value, in a single rounding mode (four such tests if you want to verify conversions for each of SFmode and DFmode, in each of two rounding modes). Of course that test wouldn't have any of the dg-* related to __float128, because this isn't a float128 issue. Given such a test that uses volatile as appropriate and just does and checks one conversion, we can be confident we have a real issue (not something about code movement). If such a test shows a bug, it will be somewhere in the libgcc2.c code, with the appropriate fix being in that code. Since that code has lots of conditionals in it, it would help to identify exactly which cases in that code are used; that is, which of the #if FSSIZE >= W_TYPE_SIZE #elif (LIBGCC2_HAS_DF_MODE && F_MODE_OK (__LIBGCC_DF_MANT_DIG__)) \ || (LIBGCC2_HAS_XF_MODE && F_MODE_OK (__LIBGCC_XF_MANT_DIG__)) \ || (LIBGCC2_HAS_TF_MODE && F_MODE_OK (__LIBGCC_TF_MANT_DIG__)) or #else cases is being used (and, in the second case, what FSIZE and FTYPE are). The bug could either be in the code in the selected case, or in the logic that selects which case to use. Based on code inspection, it's possible the issue is with /* No leading bits means u == minimum. */ if (count == 0) return -(Wtype_MAXp1_F * (Wtype_MAXp1_F / 2)); in the third case (where actually count == 0 only means the high part is minimum). In which case something like return Wtype_MAXp1_F * (FSTYPE) (hi | ((UWtype) u != 0)); for the (count == 0) case would address the problem. -- Joseph S. Myers joseph@codesourcery.com