From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23931 invoked by alias); 8 Feb 2005 04:03:32 -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 23911 invoked from network); 8 Feb 2005 04:03:26 -0000 Received: from unknown (HELO copland.sibelius.xs4all.nl) (24.75.92.210) by sourceware.org with SMTP; 8 Feb 2005 04:03:26 -0000 Received: from copland.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by copland.sibelius.xs4all.nl (8.13.3/8.13.0) with ESMTP id j1843N7t023326 for ; Tue, 8 Feb 2005 05:03:24 +0100 (CET) Received: (from kettenis@localhost) by copland.sibelius.xs4all.nl (8.13.3/8.13.3/Submit) id j1843N75006954; Tue, 8 Feb 2005 05:03:23 +0100 (CET) Date: Tue, 08 Feb 2005 10:11:00 -0000 Message-Id: <200502080403.j1843N75006954@copland.sibelius.xs4all.nl> From: Mark Kettenis To: gdb@sources.redhat.com Subject: Bug in valarith.c:value_equal()? X-SW-Source: 2005-02/txt/msg00034.txt.bz2 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