From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15918 invoked by alias); 19 Mar 2004 08:11:21 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 15904 invoked from network); 19 Mar 2004 08:11:17 -0000 Received: from unknown (HELO mailgate.urz.tu-dresden.de) (141.30.66.154) by sources.redhat.com with SMTP; 19 Mar 2004 08:11:17 -0000 Received: from [127.0.0.1] (helo=localhost) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) id 1B4F64-0005Xm-5B; Fri, 19 Mar 2004 09:11:16 +0100 Received: from mailgate.urz.tu-dresden.de ([127.0.0.1]) by localhost (rks24 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21011-08; Fri, 19 Mar 2004 09:11:15 +0100 (MET) Received: from [141.30.17.64] (helo=ptprs1.phy.tu-dresden.de) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) id 1B4F63-0005Xc-D6; Fri, 19 Mar 2004 09:11:15 +0100 Received: from physik.tu-dresden.de (ptpp80.phy.tu-dresden.de [141.30.17.240]) by ptprs1.phy.tu-dresden.de (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA16802; Fri, 19 Mar 2004 09:11:14 +0100 Message-ID: <405AAC97.60308@physik.tu-dresden.de> Date: Fri, 19 Mar 2004 11:30:00 -0000 From: Thomas Kunert User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Roger Sayle CC: gcc@gcc.gnu.org Subject: Re: x87 float truncation/accuracy (gcc vs. icc/msvc) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-TUD-Virus-Scanned: by amavisd-new at rks24.urz.tu-dresden.de X-TUD-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on rks24 X-SW-Source: 2004-03/txt/msg01115.txt.bz2 Roger Sayle wrote: > interesting is that both the Microsoft Visual C/C++ compiler and Intel's > icc both *by default* completely optimized away this "float_truncate", > producing incorrectly rounded results. > Could you please explain what's wrong with incorrectly rounded results? I was under the impression accuracy and performance is more important to most people. And for the ones who actually care about rounding there is -ffloat-store. What is this option for, if the truncation happens anyway? The current behavior is very surprising, at least to me. Excess precision is documented and known by most people doing numerical applications. On the other hand, a performance impact for the sake of correct rounding is surprising and very annoying here, especially since one cannot turn it off. And please don't expect everyone to use a flag named unsafe-math-optimizations. Thanks, Thomas Kunert