From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-116816-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 18484 invoked by alias); 5 Jul 2005 18:32:32 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 18460 invoked by uid 22791); 5 Jul 2005 18:32:27 -0000
Received: from smtp-102-tuesday.noc.nerim.net (HELO mallaury.nerim.net) (62.4.17.102)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 05 Jul 2005 18:32:27 +0000
Received: from uniton.integrable-solutions.net (gdr.net1.nerim.net [62.212.99.186])
	by mallaury.nerim.net (Postfix) with ESMTP id 278FC4F3A8;
	Tue,  5 Jul 2005 20:32:14 +0200 (CEST)
Received: from uniton.integrable-solutions.net (localhost [127.0.0.1])
	by uniton.integrable-solutions.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j65IVHKY007325;
	Tue, 5 Jul 2005 20:31:17 +0200
Received: (from gdr@localhost)
	by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id j65IVH1H007324;
	Tue, 5 Jul 2005 20:31:17 +0200
To: Joe Buck <Joe.Buck@synopsys.COM>
Cc: gcc@gcc.gnu.org
Subject: Re: tr1::unordered_set<double> bizarre rounding behavior (x86)
References: <OF340AFDFE.4774C997-ON43257035.003F59A4-43257035.0047DBFD@il.ibm.com>
	<42CABDCC.3070508@suse.de>
	<m3hdf9b024.fsf@uniton.integrable-solutions.net>
	<20050705181025.GB2315@synopsys.com>
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
In-Reply-To: <20050705181025.GB2315@synopsys.com>
Date: Tue, 05 Jul 2005 18:32:00 -0000
Message-ID: <m34qb9qf4a.fsf@uniton.integrable-solutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2005-07/txt/msg00180.txt.bz2

Joe Buck <Joe.Buck@synopsys.COM> writes:

| On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| > It is definitely a good thing to use the full bits of value
| > representation if we ever want to make all "interesting" bits part of
| > the hash value.  For reasonable or sane representations it suffices to
| > get your hand on the object representation, e.g.:
| > 
| >    const int objsize = sizeof (double);
| >    typedef unsigned char objrep_t[objsize];
| >    double x = ....;
| >    objrep_t& p = reintepret_cast<objrep_t&>(x);
| >    // ...
| > 
| > and let frexp and friends only for less obvious value representation.
| 
| I disagree; on an ILP32 machine, we pull out only 32 bits for the hash
| value, and if you aren't careful, your approach will wind up using the
| least significant bits of the mantissa.  This will cause all values that
| are exactly representable as floats to collide.

I'm not sure we're talking about the same thing.  With the
representations I'm talking about, value repsentation == object representation.