Possible compiler bug?

I am not quick to leap to this conclusion, but...

I have a bit of code for doing a color space conversion (RGB to HSB). This
is not a trvial conversion but it isn't that complicated either. It is just
really a 3D coordinate conversion.

It works perfectly well in the IDE. When running the application direcly, it
mainly works, except for a certain narrow band of colors the calculation
goes wrong.

Unfortunately, any attempt to add debug seems to make the problem disappear.
Indeed, even the inclusion of a line of code which has no effect, eg int x =
y; when x is never used again, makes the problem go away.

The only remotely dodgy thing about the code (it is "standard" code, at
least in its C++ form, I didn't write it) is that it compares 2 floats for
equality. To be fair, it first assigns a to b, and then later tests if a==b,
so it should work.

Howevr I wonder if some compiler bug is mistakenly deciding the values
cannot be equal in some cases.

Anyway I changed the logic to use flags and it works. But that diesn't prove
much.

Dom

Stunning fractal photographs
http://www.morello.co.uk/fractal.htm

Would be nice if you could post some code.
But the float comparison could be the reason since calculated float values
are sometimes stored into 80 bit registers and sometimes into 64 bit
registers.
And if you assign a flaot that is stored in a 80 bit register to one that is
stored in a 64 bit register you can lose some digits and successive equality
tests will give false even the same value was originally assigned to both of
them.

"anon" <noone@nowhere.spam> schrieb im Newsbeitrag
news:41d9e4e2$1_1@alt.athenanews.com...
>I am not quick to leap to this conclusion, but...
>
> I have a bit of code for doing a color space conversion (RGB to HSB). This
> is not a trvial conversion but it isn't that complicated either. It is
> just
> really a 3D coordinate conversion.
>
> It works perfectly well in the IDE. When running the application direcly,
> it
> mainly works, except for a certain narrow band of colors the calculation
> goes wrong.
>
> Unfortunately, any attempt to add debug seems to make the problem
> disappear.
> Indeed, even the inclusion of a line of code which has no effect, eg int x
> =
> y; when x is never used again, makes the problem go away.
>
> The only remotely dodgy thing about the code (it is "standard" code, at
> least in its C++ form, I didn't write it) is that it compares 2 floats for
> equality. To be fair, it first assigns a to b, and then later tests if
> a==b,
> so it should work.
>
> Howevr I wonder if some compiler bug is mistakenly deciding the values
> cannot be equal in some cases.
>
> Anyway I changed the logic to use flags and it works. But that diesn't
> prove
> much.
>
> Dom
>
> Stunning fractal photographs
> http://www.morello.co.uk/fractal.htm
>
>

If I could find a small bit of code which showed the problem I would post
it - but even tiny changes to the code seem to alter the situation so I am
doubtful of the chances of finding a small example. The problem is in the
middle of a large library.

What you are saying seems to make sense (at least, yet another straw to
clutch at :) Do you know how the compiler would choose which type of float
to use? Why would it be different for the IDE?

Would it help to use doubles? Your theory would explain why my alternative
flag implementation works, at least.

Dom



"cody" <deutronium@gmx.de> wrote in message
news:#7OtIsf8EHA.3840@tk2msftngp13.phx.gbl...
> Would be nice if you could post some code.
> But the float comparison could be the reason since calculated float values
> are sometimes stored into 80 bit registers and sometimes into 64 bit
> registers.
> And if you assign a flaot that is stored in a 80 bit register to one that
is
> stored in a 64 bit register you can lose some digits and successive
equality
> tests will give false even the same value was originally assigned to both
of
> them.
>
> "anon" <noone@nowhere.spam> schrieb im Newsbeitrag
> news:41d9e4e2$1_1@alt.athenanews.com... 
This 
direcly, 
x 
for 
>
>