From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11800 invoked by alias); 30 May 2005 15:28:29 -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 9252 invoked by uid 22791); 30 May 2005 15:22:49 -0000 Received: from monty-python.gnu.org (HELO monty-python.gnu.org) (199.232.76.173) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 30 May 2005 15:22:49 +0000 Received: from [62.212.121.106] (helo=ay.vinc17.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DchFF-00066s-7S for gcc@gcc.gnu.org; Mon, 30 May 2005 06:11:43 -0400 Received: from lefevre by ay.vinc17.org with local (Exim 4.50) id 1DchDh-0007zD-E1; Mon, 30 May 2005 12:10:05 +0200 Date: Mon, 30 May 2005 15:34:00 -0000 From: Vincent Lefevre To: gcc@gcc.gnu.org Subject: Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point] Message-ID: <20050530101005.GF3541@ay.vinc17.org> Mail-Followup-To: gcc@gcc.gnu.org References: <002d01c5643c$cfcc1140$bebc2997@bagio> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailer-Info: http://www.vinc17.org/mutt/ User-Agent: Mutt/1.5.9-vl-20050401i X-SW-Source: 2005-05/txt/msg01608.txt.bz2 On 2005-05-29 18:19:19 +0300, Michael Veksler wrote: > If more than 50 people report it, independently, as a bug then it > sure is a bug. You might argue whether technically it is a bug, but > from user's perspective it is a bug (and you have over 50 duplicates > as an evidence). As such it has to be dealt with more positively. Concerning the extended precision, there are two problems. First there is a bug in GCC concerning casts and assignments (see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2). But even this were fixed, many users would still complain. That's why I think that the Linux kernel should set the CPU in double-precision mode, like some other OS's (MS Windows, *BSD) -- but this is off-topic here. I've written a web page about that: http://www.vinc17.org/research/extended.en.html > I also think that it is also a bug from the technical angle. As far > as I know, there is an IEEE standard that dictates things like > rounding. I don't have it in front of me now, but as I remember it > refers mostly to CPU's floating point unit. So if the CPU does not > meet the standard, GCC can say that it is a bug in the CPU. The IEEE-754 standard allows extended precision, even though the C type is double precision. The term used by the IEEE-754 standard is "destination", but doesn't specify what the "destination" is. It may be a floating-point register. > The standpoint that it's a bug in the CPU is unproductive. It would > help the users if GCC were trying to hide IEEE nonconformance as > much as possible. Things such as I agree that GCC should try to hide IEEE non-conformance (but x86 CPUs are conforming IEEE-754 implementations, modulo some particular bugs). > assert( a / b == a / b); > should not fail according to IEEE (as far as I remember). According to IEEE, it may fail, for various reasons. In particular because the IEEE-754 standard does not have language bindings. Also note that a CPU may have two floating-point units, one conventional in extended precision and one in double precision (e.g. SSE2), and they could be used in parallel (this was an example by Fred J. Tydeman on the stds-754 list). But if you do, double x = a / b; double y = a / b; double z = a / b; at least two of x, y, z should be equal if the processor supports the IEEE-754 standard, even with any extended precision internally. > An even more surprising example can be created: > #include > volatile float x=3; > int main() > { > float a = 1/x; > x = a; > assert(a == x); // -O2 will fail on gcc-3.4.3 and gcc-4.0.0 > } Yes, this is the bug in GCC I was talking about (the one concerning the assignments). > I think that you can't deny it is a bug. Copying a variable of the > same type should not change its value (regardless of what == > generally means in FP context). Yes. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / SPACES project at LORIA