This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/33971] New: Type promotion in mixed integer / floating point arithmetic and rounding
- From: "hudson+gcc at osresearch dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 1 Nov 2007 14:26:48 -0000
- Subject: [Bug c/33971] New: Type promotion in mixed integer / floating point arithmetic and rounding
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
This may be another addition to bug 323, although it doesn't involve floating
point comparison. I am integrating the output of (drand48()-0.5)*10 with an
integer and get wildly different results for "x += r" versus "x += (int) r",
where x is an integer and r is a value from drand48. I would expect a random
walk around the initial value for x in both cases, but in the first case the
integrated value heads directly towards zero and then random walks around zero,
while the second remains around the initial value.
Looking at the assembly output, it appears that the first converts x to a
double, performs the arithmetic as floating point, then converts back to and
integer, while the second converts the floating point random value to an
integer and then does the add as an integer. The results are the same on
i386-redhat-linux as x86_64.
#include <stdio.h>
#include <stdlib.h>
int main( void )
{
int iter = 100000;
int x = 1000;
int y = 1000;
double z = 1000;
while( iter-- > 0 )
{
double r = (drand48() - 0.5) * 10;
x += r;
y += (int) r;
z += r;
printf( "%d %d %.0f\n", x, y, z );
}
return 0;
}
A graph of the output showing the x value going straight to zero and the other
two doing their random walk is at http://www.swcp.com/~hudson/rand.png
--
Summary: Type promotion in mixed integer / floating point
arithmetic and rounding
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hudson+gcc at osresearch dot net
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33971