From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29462 invoked by alias); 22 Nov 2010 19:30:57 -0000 Received: (qmail 29448 invoked by uid 22791); 22 Nov 2010 19:30:55 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Nov 2010 19:30:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 130042BAC18; Mon, 22 Nov 2010 14:30:45 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5zHC1iWWL1ef; Mon, 22 Nov 2010 14:30:45 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D41EA2BAC0D; Mon, 22 Nov 2010 14:30:44 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 01F601457E1; Mon, 22 Nov 2010 11:30:41 -0800 (PST) Date: Mon, 22 Nov 2010 19:30:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [patch 2/2] iFort compat.: case insensitive symbols (PR 11313) Message-ID: <20101122193041.GU2634@adacore.com> References: <20101108183133.GE2933@adacore.com> <20101122035334.GA9229@host0.dyn.jankratochvil.net> <20101122185432.GT2634@adacore.com> <20101122191905.GA20976@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101122191905.GA20976@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-11/txt/msg00309.txt.bz2 > If there are any concerns about it (I do not think there should be any while > looking and the disassembly plus glibc's __ctype_tolower_loc) we should also > ask why GDB already uses locale-conforming tolower while gcc uses TOLOWER. > > GDB could also use it, it is in libiberty. That one has "zero" cost. I was actually wondering about the change in the hash algorithm more than the cost of calling tolower. For instance, "tmp" and "Tmp" would have had different hash values, but not anymore. So, presumably, when you start looking up for "tmp", the associated hash bucket will also contain "Tmp" whereas it wouldn't before. I need to look at the actual hashing parameters to see if we can figure out whether this should have any real effect in practice... If the number of elements in each bucket is reasonable, a few more iterations shouldn't be an issue. -- Joel