From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12770 invoked by alias); 20 Feb 2005 05:51:53 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12740 invoked from network); 20 Feb 2005 05:51:49 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 20 Feb 2005 05:51:49 -0000 Received: from [10.0.1.3] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (rwcrmhc12) with SMTP id <2005022005514801400ircuie>; Sun, 20 Feb 2005 05:51:48 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 20 Feb 2005 20:37:00 -0000 Subject: Re: [RFC/RFA] Fix varobj.c value comparison problems From: Paul Schlie To: Andrew Cagney , Mark Kettenis , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-02/txt/msg00211.txt.bz2 > Mark Kettenis wrote: >> Andrew Cagney wrote: >> Mark, the thing that's missing is an automated testcase. Having >> something change from -0.0 to +0.0 should do it. > > Ah, but that is the exact the opposite of what triggered this fix: > > NaN != NaN > > even though the bit pattern is the same, whereas > > -0.0 == +0.0 Don't know where the notion of -0.0 == +0.0 is derived from, as they clearly express different semantics: 1/-0.0 => -inf 1/+0.0 => +inf Therefore clearly aren't equivalent; although +0.0 == abs(-0.0) is. Nor correspondingly, is it sensible that Nan != NaN; as regardless of their indeterminate respective values, they express equivalent semantics. Apparently, a few of the bits of wisdom brought to us by committees.