From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60331 invoked by alias); 22 Jan 2019 00:40:41 -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 60322 invoked by uid 89); 22 Jan 2019 00:40:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:209.85.210.194, H*RU:209.85.210.194, HX-HELO:sk:mail-pf X-HELO: mail-pf1-f194.google.com Received: from mail-pf1-f194.google.com (HELO mail-pf1-f194.google.com) (209.85.210.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 Jan 2019 00:40:39 +0000 Received: by mail-pf1-f194.google.com with SMTP id b7so10861931pfi.8 for ; Mon, 21 Jan 2019 16:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+v5psyx1m86hMCutKJToQd4Vz0uBTsUOaG6C6nDb3jA=; b=IZkeQIpgtKcpCLZsQMBsqmz+htew58eR271CP54w+1hGnXQST8Q4dFqquqDzXqoyrq Sbs9WiiAZ8xm9Qv3pJRmfcuUg4FloZFcozxfcRMB3v7ZFdN7TewIj5n3xjcicTeGI0oR XqTQtpmjZgtYBVbaA9VkfZaKik/DkLIq6N7wrSty5jlLh8VrVcJrM7GIO8QhfJ6IUBOJ Du8O81kw7+Pc58bsvDMw5MInRSCPeKeYoYdmVvv2T1kmd3Au+KmJe0qW47lYQQLQkc4g OSjiAwUCvobmG6K2p9eYVX/ceqFMc4Ayw6ZuH8eZmDxHJaEDWGzGFFbHIHzeqVII74GA kYiA== MIME-Version: 1.0 References: <20190121161546.2900-1-hjl.tools@gmail.com> In-Reply-To: From: Terry Guo Date: Tue, 22 Jan 2019 00:40:00 -0000 Message-ID: Subject: Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp To: Joseph Myers Cc: "H.J. Lu" , gcc-patches , Uros Bizjak Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg01255.txt.bz2 On Tue, Jan 22, 2019 at 7:48 AM Joseph Myers wrote: > > 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 Hi Joseph, I believe HJ is proposing patch to fix bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931. In the test case of the bug, the "#pragma STDC FENV_ACCESS ON" is used and there are four rounding modes: { ROUNDING (FE_DOWNWARD), ROUNDING (FE_UPWARD), ROUNDING (FE_TOWARDZERO), ROUNDING (FE_TONEAREST) } The current _floattisf from libgcc2 doesn't support those four rounding modes. BR, Terry