Re: [dev] dwm-5.6

On 7/20/09, sqweek <sqweek_AT_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
Received on Mon Jul 20 2009 - 21:29:32 UTC