From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21410 invoked by alias); 8 Feb 2005 15:35:05 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21399 invoked from network); 8 Feb 2005 15:35:01 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Feb 2005 15:35:01 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j18FYtwF015079 for ; Tue, 8 Feb 2005 10:35:01 -0500 Received: from localhost.redhat.com (vpn50-111.rdu.redhat.com [172.16.50.111]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j18FYoO28823; Tue, 8 Feb 2005 10:34:50 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E334E7D79; Tue, 8 Feb 2005 10:34:22 -0500 (EST) Message-ID: <4208DBFE.50805@gnu.org> Date: Tue, 08 Feb 2005 15:46:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: Bug in valarith.c:value_equal()? References: <200502080403.j1843N75006954@copland.sibelius.xs4all.nl> In-Reply-To: <200502080403.j1843N75006954@copland.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00036.txt.bz2 Mark Kettenis wrote: Your right, varobj should use bitwise comparison. Suggest a function value_content_equal. Andrew > I've found the cause of the testsuite problems I reported yesterday. > The additional testsuite failures are intermittent. If you look > careful at the gdb.mi/mi-var-cmd.exp test you'll see that the test is > checking whether some uninitialized local variables have been changed. > The testsuite failures indicate that sometimes, the floating-point > variables change unexpectedly. Some further investigation showed that > these unexpected changes happened when the (unitialized) variables > were NaNs. All of a sudden things make sense. The variables don't > really change. GDB tries to determine whether a variable changes by > comparing its current value to a previous value. This is done by > calling valarith.c:value_equal(). For floating-point variables, this > function does the following check: > > return value_as_double (arg1) == value_as_double (arg2); > > Now in C this will return 0, if ARG1 and ARG2 are NaN, even if they > are bit for bit equal. > > Actually I think the implementation of valarithm.c:value_equal() is > right; when GDB evaluates expressions NaN == NaN should be zero. > Therefore I think we shouldn't use this function when establishing > when a variable has been changed. Does it make sense to simply do a > bit-for-bit comparison in that case? > > Mark > > >