From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13785 invoked by alias); 5 Jul 2005 13:32:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13772 invoked by uid 22791); 5 Jul 2005 13:32:26 -0000 Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 05 Jul 2005 13:32:26 +0000 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id E0E231D6E9; Tue, 5 Jul 2005 15:32:23 +0200 (CEST) Message-ID: <42CA8C18.1030606@suse.de> Date: Tue, 05 Jul 2005 13:32:00 -0000 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 MIME-Version: 1.0 To: Michael Veksler Cc: gcc@gcc.gnu.org Subject: Re: tr1::unordered_set bizarre rounding behavior (x86) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-07/txt/msg00149.txt.bz2 Michael Veksler wrote: >The behavior of the second run does not look right. What does it mean? >1. Is it forbidden by tr1 to define unordered_set ? >2. Is it a bug in the tr1 document (which should have forbidden this). >3. Is it OK to have repetitions in unordered_set? >4. Is it a bug in gcc, for handling double the way it does? >5. Is it a bug in the implementation of tr1 in libstdc++ ? > Maybe handling of double should move to a different > translation unit, to avoid aggressive inlining. Or maybe > there should be a specialization for equal_to, > where error bands will be used. > > I can see two possibilites here. Either: 1. You know the answer. Then you should probably discuss it, preferably comparing gcc to other compilers and mentioning specific sections of the Standard, TR1, LIA*, and so on. 2. You don't know the answer. In that case you are supposed to file a PR and trust bug-masters and maintainers about the issue. > std::tr1::hash is implemented in a very bad way. > it casts double to size_t, which of course does a very poor job on big > values (is the result of 1.0e100 cast to size_t defined ?). > > Thanks. Patches welcome, as usual: contributions are certainly encouraged, especially so from IBM - I would say - generally committed to the project in a constructive, high quality, and friendly way. Paolo.