Compiler bug????

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> That is what I'm suggesting.  Below is an example of something for the=
=20
>> longest time I couldn't understand, i.e., why the yrang here is as it=20
>> is.  The y range could be forced to make it look better.
>=20
>=20
> Well, guess what: I just tried that example myself (OpenWatcom build fo=
r=20
> MS Windows, terminal windows), and got nothing like what you got in
> that PNG.  The yrange I got was [1:2], exactly as expected.
>=20
>> What is happening there?
>=20
>=20
> Whatever it is --- it's not happening here where I sit and type this ;-=
)
>=20
> You'll have to debug that yourself, I think.

I still can't believe what I'm seeing.  Coming into the round_outward() f=
unction, the following two lines of code:

fprintf(stderr, "FLOOR %d\n", (int)floor(input / tic));
fprintf(stderr, "FLOOR %d\n", (int)floor(input / tic));

produce:

FLOOR 4
FLOOR 5

I assume most people are using a more recent version of gcc than I am:

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=3D/usr --mandir=3D/usr/share/man -=
-infodir=3D/usr/share/info --enable-shared --enable-threads=3Dposix --dis=
able-checking --wiith-system-zlib --enable-__cxa_atexit --disable-libunwi=
nd-exceptions --enable-java-awt=3Dgtk --host=3Di386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

Dan