On 6/18/06, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Zdenek Dvorak wrote:
>... I suspect there is something wrong with your
>code (possibly invoking some undefined behavior, using uninitialized
>variable, sensitivity to rounding errors, or something like that).
>
>
A data point apparently in favor of this suspect is that the "problem"
goes away if double is replaced everywhere with long double...
Paolo.
As suspected by everybody, this is a bug in the code.
From your original code:
110 coord[i]=start[i]+maxT[whichPlane]*dir[i];
111 // **** Uncomment one of these to make the program work.
112 //sleep(0);
113 //cerr << "";
114 if ((coord[i]<ll[i]) || (coord[i]>ur[i])) {
115 // outside box
116 return false;
117 }
The compiler is allowed to calculate coord[i] at 110 in 80-bit
and use that in the comparison at line 114.
One way to see this impact, without debugging at the assembly level,
is to change the code to:
110 long double temp;
111 temp = start[i]+maxT[whichPlane]*dir[i];
112 // **** Uncomment one of these to make the program work.
113 //sleep(0);
114 //cerr << "";
115 if ((temp<ll[i]) || (temp>ur[i])) {
If you try this code, you'll find that this always fails
and if you inspect temp and ur[i], you'll find that they are very close -
within 1 ULP of double precision.
One bandaid for this problem is to use -ffloat-store
but you'll suffer the performance penalty and it won't really fix
the root cause - which is your code.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
