From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23207 invoked by alias); 29 May 2005 18:32:57 -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 23183 invoked by uid 22791); 29 May 2005 18:32:51 -0000 Received: from admin.voldemort.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 29 May 2005 18:32:51 +0000 Received: (qmail 25954 invoked from network); 29 May 2005 18:32:49 -0000 Received: from localhost (HELO digraph.polyomino.org.uk) (joseph@127.0.0.1) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 29 May 2005 18:32:49 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.51) id 1DcSad-0007Ey-PS; Sun, 29 May 2005 18:32:47 +0000 Date: Sun, 29 May 2005 20:13:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Giovanni Bajo cc: Vincent Lefevre , gcc@gcc.gnu.org Subject: Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point] In-Reply-To: <002d01c5643c$cfcc1140$bebc2997@bagio> Message-ID: References: <42988B8C.2090905@kss-loka.si> <20050528225238.GC5967@ay.vinc17.org> <002d01c5643c$cfcc1140$bebc2997@bagio> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-05/txt/msg01590.txt.bz2 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. Many of the issues reported in 323 or duplicates may be problems of user expectations or problems that -ffloat-store fixes, but there are still these subsets which are genuine bugs. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ jsm@polyomino.org.uk (personal mail) joseph@codesourcery.com (CodeSourcery mail) jsm28@gcc.gnu.org (Bugzilla assignments and CCs)