* What the hell is going on? Just a simple division...
@ 1999-12-21 13:14 Paul E.C. Melis
1999-12-24 11:00 ` David Wragg
1999-12-31 22:24 ` Paul E.C. Melis
0 siblings, 2 replies; 4+ messages in thread
From: Paul E.C. Melis @ 1999-12-21 13:14 UTC (permalink / raw)
To: help-gcc
/*
Using gcc-2.95.2 and linux 2.0.35 (libc5) the
following program gives as output
0
1
instead of the obviously correct output
1
1
Is this a compiler bug?
I have a Celeron 333 by the way. /proc/cpuinfo
reports that it doesn't have an fdiv bug.
Paul (melis@cs.utwente.nl)
*/
#include <math.h>
#include <stdio.h>
int main (int argc, char *argv[])
{
printf ("%d\n", (int) ( log(2.0) / log(2.0) ));
printf ("%d\n", (int) ( log10(2.0) / log10(2.0) ));
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: What the hell is going on? Just a simple division...
1999-12-21 13:14 What the hell is going on? Just a simple division Paul E.C. Melis
@ 1999-12-24 11:00 ` David Wragg
1999-12-31 22:24 ` David Wragg
1999-12-31 22:24 ` Paul E.C. Melis
1 sibling, 1 reply; 4+ messages in thread
From: David Wragg @ 1999-12-24 11:00 UTC (permalink / raw)
To: help-gcc
"Paul E.C. Melis" <melis@cs.utwente.nl> writes:
> Using gcc-2.95.2 and linux 2.0.35 (libc5) the
> following program gives as output
> 0
> 1
> instead of the obviously correct output
> 1
> 1
> Is this a compiler bug?
No. Just a pitfall of floating point on x86.
> printf ("%d\n", (int) ( log(2.0) / log(2.0) ));
Look at the generated assembly. One "log(2.0)" gets evaluated to a
double held in an 80-bit FP register. This is then transfered to a
64-bit double in memory, causing it to be rounded. The other
"log(2.0)" is then evaluated to a double held in an 80-bit bit FP
register. The division is then performed. Since only one value was
rounded, the result will not be 1.0, and so on conversion to int may
be truncated to 0.
David Wragg
^ permalink raw reply [flat|nested] 4+ messages in thread
* What the hell is going on? Just a simple division...
1999-12-21 13:14 What the hell is going on? Just a simple division Paul E.C. Melis
1999-12-24 11:00 ` David Wragg
@ 1999-12-31 22:24 ` Paul E.C. Melis
1 sibling, 0 replies; 4+ messages in thread
From: Paul E.C. Melis @ 1999-12-31 22:24 UTC (permalink / raw)
To: help-gcc
/*
Using gcc-2.95.2 and linux 2.0.35 (libc5) the
following program gives as output
0
1
instead of the obviously correct output
1
1
Is this a compiler bug?
I have a Celeron 333 by the way. /proc/cpuinfo
reports that it doesn't have an fdiv bug.
Paul (melis@cs.utwente.nl)
*/
#include <math.h>
#include <stdio.h>
int main (int argc, char *argv[])
{
printf ("%d\n", (int) ( log(2.0) / log(2.0) ));
printf ("%d\n", (int) ( log10(2.0) / log10(2.0) ));
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: What the hell is going on? Just a simple division...
1999-12-24 11:00 ` David Wragg
@ 1999-12-31 22:24 ` David Wragg
0 siblings, 0 replies; 4+ messages in thread
From: David Wragg @ 1999-12-31 22:24 UTC (permalink / raw)
To: help-gcc
"Paul E.C. Melis" <melis@cs.utwente.nl> writes:
> Using gcc-2.95.2 and linux 2.0.35 (libc5) the
> following program gives as output
> 0
> 1
> instead of the obviously correct output
> 1
> 1
> Is this a compiler bug?
No. Just a pitfall of floating point on x86.
> printf ("%d\n", (int) ( log(2.0) / log(2.0) ));
Look at the generated assembly. One "log(2.0)" gets evaluated to a
double held in an 80-bit FP register. This is then transfered to a
64-bit double in memory, causing it to be rounded. The other
"log(2.0)" is then evaluated to a double held in an 80-bit bit FP
register. The division is then performed. Since only one value was
rounded, the result will not be 1.0, and so on conversion to int may
be truncated to 0.
David Wragg
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-12-31 22:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-12-21 13:14 What the hell is going on? Just a simple division Paul E.C. Melis
1999-12-24 11:00 ` David Wragg
1999-12-31 22:24 ` David Wragg
1999-12-31 22:24 ` Paul E.C. Melis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).