From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53966 invoked by alias); 22 Jan 2019 01:34:48 -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 53955 invoked by uid 89); 22 Jan 2019 01:34:48 -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= X-HELO: mail-ot1-f67.google.com Received: from mail-ot1-f67.google.com (HELO mail-ot1-f67.google.com) (209.85.210.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 Jan 2019 01:34:46 +0000 Received: by mail-ot1-f67.google.com with SMTP id t5so17219858otk.1 for ; Mon, 21 Jan 2019 17:34:46 -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=KsJakuRVq+LoAlQZy0KF1Ps9a3/EFUB4O0YKgjYQtgQ=; b=uSwcAuKRl0ujir62K00xBYjsgWLOWy5cqsZpQpUOiEoTkN7A7VsgFBLkynzEOTNJOA sozgW1E8JaCz6dnrvlZQkBhPdl4pp8aQC+/+eUr/3IxcrNgm+1NBdamDPX/fgEAzFNOs PiM7UNW1oMZun1Kk9MeUaT615y08y7zMlzGM3L9TT6UbvsjLzTsRrceaQj1zL03WiR+D nVgIid31HnlWszhGFLHHo7hQEjkGKW0cbWveUuWiVnZVuHi7wg09dZX300htIsdOavTT ZitRCIV9Vj9JjvlEhxqLKMZP5Sdoim7+wxZheums9yYmyGQ1xMNAf9sz7IcZ5eW4Zg/c 0kmA== MIME-Version: 1.0 References: <20190121161546.2900-1-hjl.tools@gmail.com> In-Reply-To: From: "H.J. Lu" Date: Tue, 22 Jan 2019 01:34:00 -0000 Message-ID: Subject: Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp To: Joseph Myers Cc: Terry Guo , gcc-patches , Uros Bizjak Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg01257.txt.bz2 On Mon, Jan 21, 2019 at 4:58 PM Joseph Myers wrote: > > On Tue, 22 Jan 2019, Terry Guo wrote: > > > 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 > > Which isn't supported by GCC. Any test involving rounding modes should > ensure inputs and results are volatile (or use asm, etc., but volatile is > simpler for tests) to make sure that computations aren't moved across > rounding mode changes (which can happen even with -frounding-math, > -frounding-math only affects a few things like constant folding, without > preventing such code movement). > > > The current _floattisf from libgcc2 doesn't support those four rounding modes. > > It doesn't need to mention rounding modes anywhere. The basic design of > all those conversion functions is that, given the input, they determine > other inputs to other conversions with the property that only a single > floating-point rounding occurs in the sequence of operations and that the > input to that rounding is similar enough to the input to the original > operation (through careful use of sticky bits etc.) that the result of > that rounding will always be the correct result of the original operation, > independent of the rounding mode. > > For example, it's always valid, in any rounding mode, to convert TImode to > SFmode by changing the TImode input to a nicer one (at most top 64 bits > nonzero, say, so that conversions from DImode can be used as an > intermediate step) such that the top 25 bits (starting with the first > nonzero bit, for positive or unsigned arguments) of the two values agree, > and the two values also agree in whether any lower-order bits are nonzero. > That sort of thing is what the code in libgcc2.c is trying to do. > > Some of that logic is complex, and it's entirely possible it has bugs. > But the correct fix must be an architecture-independent one in libgcc2.c; > any architecture-specific version is just a subsequent optimization on top > of that. In general, for any bug, you need to work out where the buggy > code is (meaning understanding the intended interfaces between bits of the > compiler that are involved in this question), and fix it there rather than > doing a target-specific workaround. If you want to do a target-specific > workaround (like this patch is), you need to call out up front that your > patch is just a workaround and give strong justification for that approach > (e.g. some way in which the proper general fix would be destabilizing at > the current development stage). > > The current description of the bug "Wrong __floattisf and __floattidf are > selected in libgcc" is completely inappropriate unless the assertion is > that one of the #if conditionals in libgcc2.c is wrong (in which case that > #if conditional, or the code it guards, should be corrected). 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. -- H.J.