Mail Archives: cygwin/2007/06/28/13:46:26
--------------enig0DBF04976F218B3D030C1210
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Frederich, Eric P21322 wrote, On 28.6.2007 19:18:
> On Windows I have found that a program I wrote fails when compiled with
> -O1 and -O2 but runs fine with -O0.
> The program behaves correctly on Linux and Solaris with or without
> optimizations.
>=20
> The place it starts behaving differently on Windows is where two numbers
> (which should be equal) are failing a greater than or equal to (>=3D) if
> statement, but on Solaris and Linux it passes.
>=20
> My first thought was that this had to do with floating point
> representation differences on the systems but it doesn't appear to be.
> It appears to be a compiler error.
>=20
> The first thing I did was start to print out an equality matrix of the
> double array I was using.
> I was expecting to find a difference in the equality matrices between
> Linux/Solaris and Windows.
> There was none.
> This meant that two numbers which pass an equality (=3D=3D) check (for the
> purposes of printing the matrix), later failed on a greater than or
> equal to (>=3D) check which actually affected program flow.
> I then created a corresponding else statement and did some more checking
> of the two numbers and they then pass a greater than or equal to (>=3D)
> check.
>=20
> So, in summary two doubles pass on =3D=3D, then fail on >=3D, then pass =
=3D=3D,
>> =3D, <=3D while never being modified. Does this imply compiler error?
>=20
> I have attached two files example.c and example.out which are just
> excerpts from the code and output.
> In example.c I have two versions of the function where the problem is
> happening. One is the original and one has all of the debugging fprintf
> statements that produced the example.out. Both versions have the same
> bad behavior, I just wanted to include the clean one so you can see what
> it is doing.
>=20
> The function in example.c that is failing is called combineOverlaps
> which just takes line sections (on a circle) and combines them if they
> overlap into a bigger section.
> A section is a simple structure with a double "from" and a double "to".
> The equality matrix for the failing iteration (Lines 214 to 223 from
> example.out) is...
> 0 1 2 3
> ftftftft
> 0f=3D.......
> t.=3D=3D.=3D...
> 1f.=3D=3D.=3D...
> t...=3D.=3D=3D.
> 2f.=3D=3D.=3D...
> t...=3D.=3D=3D.
> 3f...=3D.=3D=3D.
> t.......=3D
>=20
> This shows that section[0]'s "to" is equal to section[1]'s "from"
> It actually passed twice since I'm printing the full matrix.
>=20
> Lines 228 to 230 of example.out are being printed from else clause
> (lines 129 to 136 in example.c) after it fails the >=3D check and shows
> that afterwards it passes all those other equality checks.
>=20
> Here is a summary of where it works and where it doesn't.
>=20
> OS Env GCC Options Pass/Fail
>=20
> Windows Msys/mingw 3.4.5 -O2 Fail
>=20
> Windows Cygwin 3.4.4 -mno-cygwin -02 Fail
> Windows Cygwin 3.4.4 -02 Fail
> Windows Cygwin 4.1.1 -02 Fail
>=20
> Windows Cygwin 3.4.4 -mno-cygwin -00 Pass
> Windows Cygwin 3.4.4 -00 Pass
> Windows Cygwin 4.1.1 -00 Pass
>=20
> Linux 4.1.1 -02 Pass
> Linux 3.4.6 -O2 Pass
>=20
> Solaris 4.1.1 -02 Pass
>=20
>=20
> It fails on Windows with any optimization in both 3.4.4 and 4.1.1, so it
> is not just happening on one particular version of the compiler.
>=20
> If a program compiled with -O0 has different output than the same
> program compiled with -O1 or -O2, is that defiantly a compile error?
> I do realize that it could be a combination of compiler optimizations
> along with the platform's representation of floating point numbers, but
> isn't that something the compiler should be aware of be careful about?
>=20
> Any insight is appreciated.
>=20
> Thanks,
> ~Eric
>=20
>=20
It is either what Dave Korn says or it could be that you are suffering from
excessive precision of x87 and rounding errors. Try to make sure that x87
rounding modes are the same on both Linux and Windows. Also try to add
-ffloat-store flag to compilation command line.
--
wilx
--------------enig0DBF04976F218B3D030C1210
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBRoPzxkNOZDESBK8FAQh95Af/ZM0hdAKc7LemRwODFeSIjxIC0YVUjD5y
+PJ9Z4QqV8sWBLTQOAdtlsw6Z9RKAtEtHojSQUkGkvJuQKfRO4wvqwwY50GFcyhr
yRXfBa7GYdsWZQnNRRnq4A6lE+CYeUIMw85O6yjEOvBAOzIB1fpLpZg1YkSO2nMO
I4keE15FRlmtyPHnZSeUbBCKlqLFGYURGsm2NwlKxPnCYwZnKfjZJvu2v76ISAiW
1lMDzv1pLpC+7On6pS5ELujmEdOnuZGdznzxDH9+hJdJzjSX7yoS3F6BN69hk/E2
eSSauL0MABGtqmTuI7CkIRjdcjsTWu+Op7Cj9ZrAgzP726cbr8dYNA==
=iQzH
-----END PGP SIGNATURE-----
--------------enig0DBF04976F218B3D030C1210--
- Raw text -