Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Daniel Berlin <dberlin@dberlin.org>]

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.