bug in Intel V7 Linux compiler?

[Marcel Cox]

This is not really a question for this list as this is not lated to GCC at
all.
Anyway, this is a typical programming bug invoking undefined behaviour, and
so the compiler is correct whatever it does.
Your error is to take the value of gjj twice in the same expression, while
incrementing it in the same expression. There is nothing that tells you
whether the compiler will take the value of gjj on the left side before or
after it increments it. Both results you posted are correct from the
compiler point of view. The compiler just decided to take a different
evaluation order in both cases.

Marcel

<GATMKORN@aol.com> wrote in message news:119.1ed63774.2b77b6ed@aol.com...
> -enclosure has what I think is a bug description for the Intel/Linux
compiler
> V7.
> best regasds GAK
>


----------------------------------------------------------------------------
----



- I get wrong results when compiling

double relval[n] ;

cadd: relval[gjj+1]+=relval[gjj++] ;

with the Intel/Linux compiler, using

icc -c -march=pentium4 -O2 adder2.c

Substituting -S for -c, my Intel/Linux compiler (Version 7, Build 2002 1021
Z) produces

cadd:
..B1.1:                         # Preds ..B1.0
        movl      gjj, %edx                #5.37
        fldl      relval+16(,%edx,8)       #5.22  is +16 correct??
        faddl     relval(,%edx,8)          #5.22
        fstpl     relval+16(,%edx,8)       #5.22  is +16 correct??
        lea       1(%edx), %eax            #5.37
        movl      %eax, gjj                #5.37
        ret                                #5.46
        .align    4,0x90

But

gcc -S -march=pentium4 -O3 -pipe -fomit-frame-pointer adder2.c

produces:

cadd:
movl gjj, %ecx
movl $relval, %eax
fldl (%eax,%ecx,8)
faddl 8(%eax,%ecx,8)
fstpl 8(%eax,%ecx,8)
addl $1, %ecx
movl %ecx, gjj
ret
.Lfe1:
.size cadd,.Lfe1-cadd
.align 2

This is different.  The gcc compiler produces correct results in my (much
larger)
application, and the Intel compiler does not.  Am I doing something wrong,
or is
this a compiler bug?

Best regards

                                      Granino A. KORN  (professor Emeritus,
U. of AZ)
                                      gatmkorn@aol.com