On 7/20/09, sqweek <sqw...@gmail.com> wrote:
>> for example
>> (double)atoi("1")/atoi("3") == (double)atoi("1")/atoi("3")
>> gives false with gcc on my x86 machine eventhough the two expressions
>> are semantically equivalent
>
> Interesting indeed, I get the same result here. However, if you store
> the division results in variables[1] you do get equality... strange.
> Maybe related to the 80-bit floating point format used internally on
> the cpu?
yes
gcc (without optimization) generates different instructions for the
two divisions, the first one uses 80bit float registers, the second
one is not
if you bind the result to variables then the difference is obviously
gone however
if ( (a = (double)atoi("1")/atoi("3"))
== (b = (double)atoi("1")/atoi("3")) )
puts("eq");
else
puts("not eq");
if (a == b)
puts("eq");
else
puts("not eq");
will print
not eq
eq
with old gcc (< 4), which is even more surprising behaviour
> I wonder if this is a gcc bug - the above expression gives me true in
> the plan 9 compilers. Longstanding one though, I see it in gcc 3.3.6,
> 3.4.6 and 4.3.2 (ie, every compiler on my system).
in c89 and the original c99 standard this is not a bug, but
'unspecified behaviour', as the standard tries to pose very limited
requirements on floating point arithmetic, so division with different
precisions is allowed
but the revised c99 standard (c99 + technical corrections ==
n1256.pdf) does not allow this, the cast operator should round
everything to double precision, so with -std=c99 it should work
correctly
for details i refer to the comp.lang.c thread i started about this issue
http://groups.google.com/group/comp.lang.c/browse_thread/thread/d4fa2a342d6779a8/1f86f6e537f6d2f1
