From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17058 invoked by alias); 30 May 2005 15:35: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 11270 invoked by uid 22791); 30 May 2005 15:27:44 -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:27:44 +0000 Received: from [68.164.203.246] (helo=dberlin.org) by monty-python.gnu.org with esmtp (SSL 3.0:RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Dcbxm-00017l-07 for gcc@gcc.gnu.org; Mon, 30 May 2005 00:33:18 -0400 Received: from [127.0.0.1] (HELO localhost) by dberlin.org (CommuniGate Pro SMTP 4.2.10) with ESMTP id 8115228; Mon, 30 May 2005 00:31:44 -0400 Subject: Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point] From: Daniel Berlin To: Vincent Lefevre Cc: gcc@gcc.gnu.org In-Reply-To: <20050528225238.GC5967@ay.vinc17.org> References: <42988B8C.2090905@kss-loka.si> <20050528225238.GC5967@ay.vinc17.org> Content-Type: text/plain Date: Mon, 30 May 2005 15:40:00 -0000 Message-Id: <1117427504.16811.34.camel@linux.site> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg01616.txt.bz2 On Sun, 2005-05-29 at 00:52 +0200, Vincent Lefevre wrote: > On 2005-05-28 17:17:32 +0200, Uros Bizjak wrote: > > At this point, I wonder what is wrong with Bugzilla, that those > > programmers don't fill a proper bug report. If there is a problem with > > GCC, that is so annoying to somebody, I think that at least developers > > could be informed about it via their standard channels of communication. > > Perhaps because GCC developers think that GCC isn't buggy when the > processor doesn't do the job for them? (I'm thinking of bug 323.) > I don't believe people feel it's not buggy, it's just that nobody has plans to fix this. This is in line with the defaults of other compilers, as well. Let's take a duplicate of 323, 21809 Compiling the code there with icc gives us: dberlin@linux:~> icc icca.c icca.c(7): warning #1572: floating-point equality and inequality comparisons are unreliable assert(a == x); ^ ./dberlin@linux:~> ./a.out a.out: icca.c:7: main: Assertion `a == x' failed. Aborted In order to get icc to not generate an executable that will abort, you have to pass special flags (the same way we have -ffloat-store, except I believe their -mp flag will just disable any optimization that could get in the way of this working). One of these flag options is to tell it to use processor specific instructions, which auto turns on the equivalent of -mfpmath=sse. Maybe if the compiler from the people who made the processor didn't do what we did, we'd be more concerned. Maybe not. But it certainly doesn't slant in favor of the vocal (what appears to be) minority to change the way we default, etc, when everyone else seems to have come to the same decision independently. --Dan PS i found this humorous for some reason: call __intel_proc_init #4.1 flds _2il0floatpacket.1 #5.17 fdivs x #5.17 fsts x #6.3 fcomps x #7.3 fnstsw %ax #7.3 sahf #7.3 jne ..B1.3 # Prob 42% #7.3 # LOE ebx esi edi ..B1.2: # Preds ..B1.1 xorl %eax, %eax #8.1 movl %ebp, %esp #8.1 popl %ebp #8.1 ret #8.1 # LOE ..B1.3: # Preds ..B1.1 push $__STRING.2 #7.3 push $7 #7.3 push $__STRING.1 #7.3 push $__STRING.0 #7.3 call __assert_fail #7.3 # LOE ..B1.6: # Preds ..B1.3 Apparently they estimate the probability of a == x succeeding at 42% for some reason (This is true at all opts levels, with and without SSE math). Why this isn't 50%, who knows.