X-Spam-Check-By: sourceware.org To: cygwin@cygwin.com From: Shankar Unni Subject: Re: strange bug in gettimeofday function Date: Mon, 19 Feb 2007 12:52:10 -0800 Lines: 23 Message-ID: References: <13811889795.20070215071733@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20070116 Thunderbird/2.0b2 Mnenhy/0.7.5.666 In-Reply-To: <13811889795.20070215071733@gnu.org> X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Andrew Makhorin wrote: > { double t0 = get_time(), t1 = get_time(); [Maybe OT?] 1. I can't remember if C guarantees that comma-separated *declarations* are initialized in order or not.. And to think I used to be an ANSI C guru :-(. 2. The reason that the "t0 > t1" fails, but t0 and t1 get dumped to be the same, is that C allows the implementation to use larger-than-64-bit (for 64-bit) intermediate double representations. In the case of X86, the CPU's floating-point registers are 80 bits wide. When they get written to stack, the value is rounded (or truncated?) to 64 bits. In the optimized code, I'll bet you that the two locals (t0 and t1) are kept entirely in registers, at least until the "&t0" and "&t1" calls. So at the point of comparison, it's comparing two 80-bit values, but when you flush them to memory to dump them as integer values, they get truncated to the (same) 64-bit value. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/