From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22941 invoked by alias); 9 Aug 2006 21:46:34 -0000 Received: (qmail 22928 invoked by uid 22791); 9 Aug 2006 21:46:33 -0000 X-Spam-Check-By: sourceware.org Received: from bethe.phy.uc.edu (HELO physics.uc.edu) (129.137.4.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Aug 2006 21:46:30 +0000 Received: from earth.geop.uc.edu (earth.phy.uc.edu [10.44.11.234]) by physics.uc.edu (8.13.6/8.13.4) with ESMTP id k79LkPZx002088; Wed, 9 Aug 2006 17:46:26 -0400 Received: from earth.phy.uc.edu (localhost.localdomain [127.0.0.1]) by earth.geop.uc.edu (8.12.11/8.9.3) with ESMTP id k79LkPHZ029222; Wed, 9 Aug 2006 17:46:25 -0400 Received: (from pinskia@localhost) by earth.phy.uc.edu (8.12.11/8.12.11/Submit) id k79LkPrx029221; Wed, 9 Aug 2006 17:46:25 -0400 From: Andrew Pinski Message-Id: <200608092146.k79LkPrx029221@earth.phy.uc.edu> Subject: Re: [Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3 To: gcc-bugzilla@gcc.gnu.org Date: Wed, 09 Aug 2006 21:46:00 -0000 Cc: gcc-bugs@gcc.gnu.org In-Reply-To: <20060809213344.16754.qmail@sourceware.org> X-Mailer: ELM [version 2.5 PL7] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 () ALL_TRUSTED X-IsSubscribed: yes Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-08/txt/msg00718.txt.bz2 List-Id: > > > > ------- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33 ------- > Dorit, > > >This flag is needed in order to allow vectorization of reduction (summation > >in your case) of floating-point data. > > OK, but this is a baaaad flag to require. From the computational scientist's > point of view, there is a *vast* difference between reordering (which many > aggressive optimizations imply) and failing to have IEEE compliance. Almost no > computational scientist will use non-IEEE code (because you have essentially no > idea if your answer is correct), but almost all will allow reordering. So, it > is really important to separate the non-IEEE optimizations from the IEEE > compliant ones. Except for the fact IEEE compliant fp does not allow for reordering at all except in some small cases. For an example is (a + b) + (-a) is not the same as (a + (-a)) + b, so reordering will invalid IEEE fp for larger a and small b. Yes maybe we should split out the option for unsafe math fp op for reordering but that is different issue. -- Pinski