From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28781 invoked by alias); 29 May 2005 18:52:25 -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 28773 invoked by uid 22791); 29 May 2005 18:52:23 -0000 Received: from web25710.mail.ukl.yahoo.com (HELO web25710.mail.ukl.yahoo.com) (217.12.10.182) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Sun, 29 May 2005 18:52:23 +0000 Received: (qmail 40180 invoked by uid 60001); 29 May 2005 18:52:21 -0000 Message-ID: <20050529185221.40178.qmail@web25710.mail.ukl.yahoo.com> Received: from [217.43.243.122] by web25710.mail.ukl.yahoo.com via HTTP; Sun, 29 May 2005 19:52:21 BST Date: Sun, 29 May 2005 20:18:00 -0000 From: Haren Visavadia Subject: Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point] To: gcc@gcc.gnu.org Cc: giovannibajo@libero.it In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2005-05/txt/msg01591.txt.bz2 --- "Joseph S. Myers" wrote: > On Sun, 29 May 2005, Giovanni Bajo wrote: > > > You are mistaken, we think GCC isn't buggy about > 323 because the C/C++ > > standards do not tell us to do better than this. > If you have higher > > expectations about floating point and C/C++, you > should file a bugreport > > against the C/C++ standards. > > This is ignoring that there are specific > requirements in the C99 standard > regarding the handling of excess precision which we > do not implement, even > with -ffloat-store, which are genuine bugs. > Assignment, casts and > function call and return must discard excess > precision, but we do not > discard excess precision on a cast of an expression > to its own type. > Furthermore, the definition of FLT_EVAL_METHOD for > i386 > > #define TARGET_FLT_EVAL_METHOD \ > (TARGET_MIX_SSE_I387 ? -1 : TARGET_SSE_MATH ? 0 : > 2) > > is wrong when it is 2 because the way the i386 back > end pretends to have > float and double (not just long double) 387 > operations means that > precision may get randomly reduced if an > intermediate value is spilled (so > -1, not 2, is correct). It is also incorrect > because it is an assertion > about both arithmetic and evaluation of constants > and we do not emulate > excess precision when evaluating constants and doing > arithmetic on them. > This makes it *bad* compiler claiming it implements a standard when does not. Giovanni Bajo stop telling lies about what GCC implements. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com