Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com From: Mark Gordon To: gilles civario Cc: cygwin AT cygwin DOT com Subject: Re: gcc bug: different results between -O0 and -O1 Date: Tue, 13 Nov 2001 14:07:31 +0000 Organization: Only Occasionally Message-ID: References: <3BEFA31B DOT B06D4C37 AT mimosa DOT ceng DOT cea DOT fr> <13971066568 DOT 20011112134524 AT logos-m DOT ru> <3BF0C475 DOT ECF56C8D AT mimosa DOT ceng DOT cea DOT fr> In-Reply-To: <3BF0C475.ECF56C8D@mimosa.ceng.cea.fr> X-Mailer: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On Tue, 13 Nov 2001 07:57:57 +0100, gilles civario wrote: >egor duda a écrit : >> Monday, 12 November, 2001 gilles civario civario AT mimosa DOT ceng DOT cea DOT fr wrote: >> >> gc> Wile developing a performance test program for gettimeofday resolution, >> gc> I found a strange behavior for gcc under cygwin with the -O flags. >> gc> Everywhere else with native compiler or with gcc, the program return constant >> gc> results, with or without optimization. (On Sun, Dec, Linux and Fujitsu) >> gc> Only with cygwin, the result is divided by 5000 from -O0 to -O1, both with >> gc> gcc version 2.95.3-5 (cygwin special) and gcc version 3.0.2. >> gc> But it shouldn't. Ok for a little increase, but not for 5000 ! >> >> you cannot reliably test float values for equality. you should rethink >> the logic of your boucle () function to get reliable results. > >I'm not sure that the problem is mine. >First, consider that this little program works fine on a large variety of >different machine, event on Linux PCs. >But, I've tried a different test for my float values : >Instead of (t2 != t1), when I use ((t2-t1)>1.E-10), I got the same results >with -O1 than with -O0. Alleluia !!! But when I use ((t2-t1)>1.E-20), I've >got the initial results and the enormous differences between the two optimization >modes. Why such a comparison gives different results when changing an >optimization flag ? And only with Cygwin ? When compiling your code the compiler is at liberty to rearrange the arithmetic (within certain parameters) if it wants. When enabling optimisation at different levels it is quite possible that it would do this and as a result cause different rounding errors. Since the C standard does not specify what goes on here it is not a bug. As to why gcc behaves differently on Cygwin to Linux or even, potentially Windows without Cygwin, this could be caused by differences in how library functions (or anything else) are implemented leading that different combinations of registers will be free making a different route optimal for different types of optimisation. If you want to know what it is doing get gcc to produce assembler files so that you can compare how it has optimised the code in different situations and on different OSs. -- Mark Gordon - To email me replace spamtrap with mark.gordon Dyslexics are teople poo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/