Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [patch 2/2] iFort compat.: case insensitive symbols (PR 11313)
Date: Mon, 22 Nov 2010 19:30:00 -0000	[thread overview]
Message-ID: <20101122193041.GU2634@adacore.com> (raw)
In-Reply-To: <20101122191905.GA20976@host0.dyn.jankratochvil.net>

> 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


  reply	other threads:[~2010-11-22 19:30 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-07  3:50 Jan Kratochvil
2010-11-08 16:36 ` Joel Brobecker
2010-11-08 17:02   ` Jan Kratochvil
2010-11-08 18:31     ` Joel Brobecker
2010-11-22  3:54       ` Jan Kratochvil
2010-11-22 18:54         ` Joel Brobecker
2010-11-22 19:19           ` Jan Kratochvil
2010-11-22 19:30             ` Joel Brobecker [this message]
2010-11-22 19:44               ` Jan Kratochvil
2010-11-22 19:57                 ` Joel Brobecker
2010-11-24 18:53                 ` Tom Tromey
2010-11-24 19:22                   ` Jan Kratochvil
2010-11-24 20:01                     ` Tom Tromey
2010-11-24 20:08                       ` Joel Brobecker
2010-11-24 21:37                         ` Tom Tromey
2010-11-24 21:45                           ` Jan Kratochvil
2010-11-24 21:55                             ` Tom Tromey
2010-11-24 20:17                       ` Jan Kratochvil
2010-11-24 20:31                         ` Joel Brobecker
2010-11-24 20:58                           ` Jan Kratochvil
2011-04-08 17:59         ` obsolete: " Jan Kratochvil
2010-11-08 17:18   ` Pierre Muller
  -- strict thread matches above, loose matches on Subject: below --
2010-11-07  3:50 [patch 1/2] Code cleanup: New init_one_comp_unit Jan Kratochvil
2010-11-12 18:36 ` Tom Tromey
2010-11-12 18:43   ` Jan Kratochvil
2010-11-12 18:46     ` Tom Tromey
2010-11-16  4:37       ` Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101122193041.GU2634@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox