[rfc] struct dictionary

[rfc] struct dictionary

[David Carlton]

I'd like to propose abstracting the symbol-storage parts of struct
block into a new struct dictionary.  Some background:

Blocks currently store symbols in one of three different ways: using a
hash table, using an unsorted list, or using a sorted list.  Most
blocks are built by buildsym.c, which use only the former two
mechanisms.  Sorted list blocks are only being produced by
mdebugread.c.  And, to make matters worse, jv-lang.c produces one
unsorted list block for which the predicate BLOCK_SHOULD_SORT matches;
the chain of events by which GDB actually treats that block correctly
is very tenuous.

This sucks.  We have this code to handle sorted linear blocks, but we
almost never use them.  We have this one block that's a complete
special case, and it's remarkable that that block still works.

And there are some other drawbacks.  For example, the only iterator
that we provide is ALL_BLOCK_SYMBOLS; it would be nice if we could
provide an iterator over all symbols with a given demangled name
(e.g. for use by make_symbol_overload_list), which would be
implemented efficiently in the hash table case and less efficiently in
the linear case, but we have no way of doing that currently.  The
block code currently isn't quite legal C; it's illegal in a way that
wouldn't normally bother me, but these days I don't trust the GCC
people to not break anything that's the slightest bit illegal.  The
Java code needs blocks that expand: this is very hard to do with the
current structure, and I could imagine other places in GDB where this
might be useful.  And probably at some point in the future, somebody
will find a good reason to add a new data structure for storing
symbols (e.g. to optimize completion or regexp searces or something);
doing so with the current architecture would be very difficult.

So I'd like to fix all of that.  I want to do this by moving that part
of struct block into a new struct called 'struct dictionary'.  This
would be an opaque data type; it has accessor functions to do
everything that you need to do to access symbols.

I've been using this on my branch for months; it works great.  The
only thing that I'm not sure about is if I got mdebugread.c right,
since I have no way to test that; I'm confident that I can fix any
problems that might arise there with a little help from testers.

So: should I go ahead with this, and prepare a formal RFA?  (I'm a
little busy right now; it won't happen this week, but maybe next week
or the following week.)  I'm including a copy of my branch's
dictionary.h after my signature so you can see the current interface
that I'm using.  It's a little out of date - e.g. it refers to
SYMBOL_BEST_NAME which was my old name for SYMBOL_NATURAL_NAME - but
hopefully it's understandable enough to be useful.

David Carlton
carlton@math.stanford.edu

/* Routines for name->symbol lookups in GDB.
   
   Copyright 2002 Free Software Foundation, Inc.

   Contributed by David Carlton <carlton@bactrian.org>.

   This file is part of GDB.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or (at
   your option) any later version.

   This program is distributed in the hope that it will be useful, but
   WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.  */

/* An opaque type for dictionaries; only dictionary.c should know
   about its innards.  */

struct dictionary;

/* Other types needed for declarations.  */

struct symbol;
struct obstack;
struct pending;


/* The creation functions for various implementations of
   dictionaries.  */

/* Create a dictionary implemented via a fixed-size hashtable.  All
   memory it uses is allocated on OBSTACK; the environment is
   initialized from SYMBOL_LIST.  */

extern struct dictionary *dict_create_hashed (struct obstack *obstack,
					      const struct pending
					      *symbol_list);

/* Create a dictionary implemented via a hashtable that grows as
   necessary.  The dictionary is initially empty; to add symbols to
   it, call dict_add_symbol().  Call dict_free() when you're done with
   it.  */

extern struct dictionary *dict_create_hashed_expandable (void);

/* Create a dictionary implemented via a fixed-size array.  All memory
   it uses is allocated on OBSTACK; the environment is initialized
   from the SYMBOL_LIST.  The symbols are ordered in the same order
   that they're found in SYMBOL_LIST.  */

extern struct dictionary *dict_create_linear (struct obstack *obstack,
					      const struct pending
					      *symbol_list);

/* Create a dictionary implemented via an array that grows as
   necessary.  The dictionary is initially empty; to add symbols to
   it, call dict_add_symbol().  Call dict_free() when you're done with
   it.  */

extern struct dictionary *dict_create_linear_expandable (void);


/* The functions providing the interface to dictionaries.  */

/* Search DICT for a symbol whose SYMBOL_BEST_NAME is NAME, as tested
   using strcmp_iw.  Returns NULL if there is no such symbol.  If
   there might be multiple such symbols, use dict_iter_name_first and
   dict_iter_name_next.  */

/* FIXME: carlton/2002-09-26: Given the presence of
   dict_iter_name_first and dict_iter_name_next, should this function
   go away?  Currently, it's never called, because all uses need the
   additional flexibility provided by dict_iter_name_first and
   dict_iter_name_next.  */

extern struct symbol *dict_lookup (const struct dictionary *dict,
				   const char *name);

/* Free the memory used by a dictionary that's not on an obstack.  (If
   any.)  */

extern void dict_free (struct dictionary *dict);

/* Add a symbol to an expandable dictionary.  */

extern void dict_add_symbol (struct dictionary *dict, struct symbol *sym);

/* Is the dictionary empty?  */

extern int dict_empty (struct dictionary *dict);

/* A type containing data that is used when iterating over all symbols
   in a dictionary.  */

/* NOTE: carlton/2002-09-11: I originally wanted to make this opaque,
   but that led to complications.  Fortunately, it turned out that all
   implementations of dictionaries currently need to keep track of the
   same types of data (though how they interpret that data varies
   depending on the implementation), so it's really not so bad after
   all.  But code outside of dictionary.c should never examine the
   innards of a dict_iterator.  */

struct dict_iterator
{
  /* The dictionary that this iterator is associated to.  */
  const struct dictionary *dict;
  /* The next two members are data that is used in a way that depends
     on DICT's implementation type.  */
  int index;
  struct symbol *current;
};

/* Initialize ITERATOR to point at the first symbol in DICT, and
   return that first symbol, or NULL if DICT is empty.  */

extern struct symbol *dict_iterator_first (const struct dictionary *dict,
					   struct dict_iterator *iterator);

/* Advance ITERATOR, and return the next symbol, or NULL if there are
   no more symbols.  Don't call this if you've previously received
   NULL from dict_iterator_first or dict_iterator_next on this
   iteration.  */

extern struct symbol *dict_iterator_next (struct dict_iterator *iterator);

/* Initialize ITERATOR to point at the first symbol in DICT whose
   SYMBOL_BEST_NAME is NAME (as tested using strcmp_iw), and return
   that first symbol, or NULL if there are no such symbols.  */

extern struct symbol *dict_iter_name_first (const struct dictionary *dict,
					    const char *name,
					    struct dict_iterator *iterator);

/* Advance ITERATOR to point at the next symbol in DICT whose
   SYMBOL_BEST_NAME is NAME (as tested using strcmp_iw), or NULL if
   there are no more such symbols.  Don't call this if you've
   previously received NULL from dict_iterator_first or
   dict_iterator_next on this iteration.  And don't call it unless
   ITERATOR was created by a previous call to dict_iter_name_first
   with the same NAME.  */

extern struct symbol *dict_iter_name_next (const char *name,
					   struct dict_iterator *iterator);


/* Macro to loop through all symbols in a dictionary DICT, in no
   particular order.  ITER is a struct dict_iterator (NOTE: __not__ a
   struct dict_iterator *), and SYM points to the current symbol.

   It's implemented as a single loop, so you can terminate the loop
   early by a break if you desire.  */

#define ALL_DICT_SYMBOLS(dict, iter, sym)			\
	for ((sym) = dict_iterator_first ((dict), &(iter));	\
	     (sym);						\
	     (sym) = dict_iterator_next (&(iter)))

/* For backwards compatibility, I suppose.  */

#define ALL_BLOCK_SYMBOLS(block, iter, sym)			\
	ALL_DICT_SYMBOLS (BLOCK_DICT (block), iter, sym)

Re: [rfc] struct dictionary

[Andrew Cagney]

> Blocks currently store symbols in one of three different ways: using a
> hash table, using an unsorted list, or using a sorted list.  Most
> blocks are built by buildsym.c, which use only the former two
> mechanisms.  Sorted list blocks are only being produced by
> mdebugread.c.  And, to make matters worse, jv-lang.c produces one
> unsorted list block for which the predicate BLOCK_SHOULD_SORT matches;
> the chain of events by which GDB actually treats that block correctly
> is very tenuous.

Um, didn't BLOCK_SHOULD_SORT get deleted?

Andrew

Re: [rfc] struct dictionary

[Daniel Jacobowitz]

On Thu, Apr 24, 2003 at 10:17:23PM -0400, Andrew Cagney wrote:
> 
> >Blocks currently store symbols in one of three different ways: using a
> >hash table, using an unsorted list, or using a sorted list.  Most
> >blocks are built by buildsym.c, which use only the former two
> >mechanisms.  Sorted list blocks are only being produced by
> >mdebugread.c.  And, to make matters worse, jv-lang.c produces one
> >unsorted list block for which the predicate BLOCK_SHOULD_SORT matches;
> >the chain of events by which GDB actually treats that block correctly
> >is very tenuous.
> 
> Um, didn't BLOCK_SHOULD_SORT get deleted?

Nope, just used less.  It's not deleted for the reasons David
describes.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] struct dictionary

[David Carlton]

On Thu, 24 Apr 2003 22:17:23 -0400, Andrew Cagney <ac131313@redhat.com> said:

>> Blocks currently store symbols in one of three different ways:
>> using a hash table, using an unsorted list, or using a sorted list.
>> Most blocks are built by buildsym.c, which use only the former two
>> mechanisms.  Sorted list blocks are only being produced by
>> mdebugread.c.  And, to make matters worse, jv-lang.c produces one
>> unsorted list block for which the predicate BLOCK_SHOULD_SORT
>> matches; the chain of events by which GDB actually treats that
>> block correctly is very tenuous.

> Um, didn't BLOCK_SHOULD_SORT get deleted?

No.  I tried in last fall, but Jim didn't like it because it probably
would have made performance for mdebugread be awful.  Daniel recently
proposed hashing sorted blocks on the fly, but he withdrew that patch
quickly when he found a way to work around whatever problem caused him
to be particularly annoyed with sorted blocks.

Basically, either somebody needs to buildsym-ify mdebugread.c or else
symbol lookup has to be made a bit more abstract.  These would
actually both be good ideas for reasons other than getting rid of
BLOCK_SHOULD_SORT, so it's certainly not an either-or choice.

David Carlton
carlton@math.stanford.edu

Re: [rfc] struct dictionary

[Andrew Cagney]

> On Thu, 24 Apr 2003 22:17:23 -0400, Andrew Cagney <ac131313@redhat.com> said:
> 
> 
>>> Blocks currently store symbols in one of three different ways:
>>> using a hash table, using an unsorted list, or using a sorted list.
>>> Most blocks are built by buildsym.c, which use only the former two
>>> mechanisms.  Sorted list blocks are only being produced by
>>> mdebugread.c.  And, to make matters worse, jv-lang.c produces one
>>> unsorted list block for which the predicate BLOCK_SHOULD_SORT
>>> matches; the chain of events by which GDB actually treats that
>>> block correctly is very tenuous.
> 
> 
>> Um, didn't BLOCK_SHOULD_SORT get deleted?
> 
> 
> No.  I tried in last fall, but Jim didn't like it because it probably
> would have made performance for mdebugread be awful.  Daniel recently
> proposed hashing sorted blocks on the fly, but he withdrew that patch
> quickly when he found a way to work around whatever problem caused him
> to be particularly annoyed with sorted blocks.

Hmm, the lack of activity towards mdebugread suggests it's either dieing 
or dead.  Perhaphs by dropping that sort we (as in the developer 
community) can encourage it in the direction we (as developers) would 
likely prefer ....

Dig dig: http://sources.redhat.com/ml/gdb-patches/2002-09/msg00564.html
My reading is that there was simply a request for more tangable numbers 
on how bad mdebug read was going to become.  So ..., what was the 
performance gain for stabs when the hash table was added?  Given that a 
binary sort's [average] performance is not as good as a hashtable, that 
number should give you an upper bound on the consequences.

Dig dig: http://sources.redhat.com/ml/gdb-patches/2001-05/msg00508.html
suggests that things could potentially be twice as slow ``Oops''. 
Looking at `break captured_main; run' I suspect it is typically less.

Assuming, now that there is a number, is this ok?  I'm willing to be the 
fall-guy (my job) and be the one adding something to the NEWS file.

> Basically, either somebody needs to buildsym-ify mdebugread.c or else
> symbol lookup has to be made a bit more abstract.  These would
> actually both be good ideas for reasons other than getting rid of
> BLOCK_SHOULD_SORT, so it's certainly not an either-or choice.

Ok, humor me ...
http://sources.redhat.com/ml/gdb/2003-04/msg00017.html
why even build these data structures during symbol reading?  It takes 
time and space, yet is probably never used.  Why not on-demand build 
this dictionary specialized for the block?  If the user for some reason 
accesses a block then, in all probablility, they will make later 
accesses to that same block - getting benefit.

> David Carlton
> carlton@math.stanford.edu

Andrew

Re: [rfc] struct dictionary

[David Carlton]

On Fri, 25 Apr 2003 11:31:35 -0400, Andrew Cagney <ac131313@redhat.com> said:

> Ok, humor me ...
> http://sources.redhat.com/ml/gdb/2003-04/msg00017.html why even
> build these data structures during symbol reading?  It takes time
> and space, yet is probably never used.  Why not on-demand build this
> dictionary specialized for the block?

That sounds great to me if we can get it to work.  It's certainly
another reason to try to get the symbol lookup stuff abstracted behind
an opaque interface: it makes lazy loading of data a lot easier.

About the mdebugread stuff: personally, I don't care about it in the
slightest, so I'm happy for its performance to degrade, and it seems
little-enough used that a 2x degradation is perfectly acceptable.
After all, if anybody really cares about it, there's an easy fix:
buildsym-ify it, so that it uses the same mechanisms everybody else
does.  Having said that, I've already done the work on my branch to
convert it to an efficient dictionary mechanism (using a combination
of hashed and unsorted linear representations); it really wasn't all
that much work.

As far as special cases go, I'm much more worried about the Java one:
the mechanism that Java uses for dynamically loaded classes is
extremely fragile, and only works through a chain of unintentional
coincidences.  Basically, it creates this block that is linear, isn't
sorted, but yet satisfies BLOCK_SHOULD_SORT, but there's special-case
code in all the symbol lookup functions to look through Java blocks
linearly instead of using sorting, where the stated reasons for doing
so are, I think, not correct, and where this one block for which it
actually _is_ necessary is never mentioned.

Also, I think that C++ could benefit from having a few special-purpose
blocks like Java does, because C++ classes and namespaces aren't
naturally tied to a single file.

David Carlton
carlton@math.stanford.edu

Re: [rfc] struct dictionary

[Andrew Cagney]

> On Fri, 25 Apr 2003 11:31:35 -0400, Andrew Cagney <ac131313@redhat.com> said:
> 
> 
>> Ok, humor me ...
>> http://sources.redhat.com/ml/gdb/2003-04/msg00017.html why even
>> build these data structures during symbol reading?  It takes time
>> and space, yet is probably never used.  Why not on-demand build this
>> dictionary specialized for the block?
> 
> 
> That sounds great to me if we can get it to work.  It's certainly
> another reason to try to get the symbol lookup stuff abstracted behind
> an opaque interface: it makes lazy loading of data a lot easier.

But which interface?

A block has a language, and [I think] it's the language that, in the end 
decides that block's name->symbol lookup strategy.  The language can, on 
demand, build a dictionary for its block.

> About the mdebugread stuff: personally, I don't care about it in the
> slightest, so I'm happy for its performance to degrade, and it seems
> little-enough used that a 2x degradation is perfectly acceptable.
> After all, if anybody really cares about it, there's an easy fix:
> buildsym-ify it, so that it uses the same mechanisms everybody else
> does.  Having said that, I've already done the work on my branch to
> convert it to an efficient dictionary mechanism (using a combination
> of hashed and unsorted linear representations); it really wasn't all
> that much work.

The alternative being simplify it, and then let the Java/C++ languages 
implement the searching schema that they need.

Andrew

Re: [rfc] struct dictionary

[David Carlton]

On Tue, 29 Apr 2003 11:10:05 -0400, Andrew Cagney <ac131313@redhat.com> said:

>> On Fri, 25 Apr 2003 11:31:35 -0400, Andrew Cagney <ac131313@redhat.com> said:
>> 

>>> Ok, humor me ...
>>> http://sources.redhat.com/ml/gdb/2003-04/msg00017.html why even
>>> build these data structures during symbol reading?  It takes time
>>> and space, yet is probably never used.  Why not on-demand build this
>>> dictionary specialized for the block?
>> That sounds great to me if we can get it to work.  It's certainly

>> another reason to try to get the symbol lookup stuff abstracted behind
>> an opaque interface: it makes lazy loading of data a lot easier.

> But which interface?

> A block has a language, and [I think] it's the language that, in the
> end decides that block's name->symbol lookup strategy.  The language
> can, on demand, build a dictionary for its block.

Currently, all uses of symbols in blocks either iterate over all
symbols or else are looking for symbols with a given natural name.  As
you say, because of the features of certain languages, sometimes you
need to refine the search further beyond that, but that's a good first
cut.  So having iterators dict_iterator_{first,next} and
dict_iter_name_{first,next} is a good first step: it unifies all the
existing mechanisms for symbol lookup, but doesn't commit to any sort
of implementation mechanism.  It certainly would allow for
constructing the actual data structures on demand: for example, we
could add an implementation that doesn't actually build the data
structures storing the symbols until the first time that an iterator
is called.

I'm certainly willing to believe that the interface might change in
the future; but separating the interface from the implementation is a
good first step no matter what.

I kind of get the impression that I'm missing your point somehow and
that we're talking past each other.  I'll post a concrete patch soon
(Wednesday, maybe?  It's done on my laptop, but I don't have my laptop
with me), and hopefully that will clarify matters.

David Carlton
carlton@math.stanford.edu

Re: [rfc] struct dictionary

[Andrew Cagney]

> On Tue, 29 Apr 2003 11:10:05 -0400, Andrew Cagney <ac131313@redhat.com> said:
> 
> 
>>> On Fri, 25 Apr 2003 11:31:35 -0400, Andrew Cagney <ac131313@redhat.com> said:
>>> 
> 
> 
>>>> Ok, humor me ...
>>>> http://sources.redhat.com/ml/gdb/2003-04/msg00017.html why even
>>>> build these data structures during symbol reading?  It takes time
>>>> and space, yet is probably never used.  Why not on-demand build this
>>>> dictionary specialized for the block?
> 
>>> That sounds great to me if we can get it to work.  It's certainly
> 
> 
>>> another reason to try to get the symbol lookup stuff abstracted behind
>>> an opaque interface: it makes lazy loading of data a lot easier.
> 
> 
>> But which interface?
> 
> 
>> A block has a language, and [I think] it's the language that, in the
>> end decides that block's name->symbol lookup strategy.  The language
>> can, on demand, build a dictionary for its block.
> 
> 
> Currently, all uses of symbols in blocks either iterate over all
> symbols or else are looking for symbols with a given natural name.  As
> you say, because of the features of certain languages, sometimes you
> need to refine the search further beyond that, but that's a good first
> cut.  So having iterators dict_iterator_{first,next} and
> dict_iter_name_{first,next} is a good first step: it unifies all the
> existing mechanisms for symbol lookup, but doesn't commit to any sort
> of implementation mechanism.  It certainly would allow for
> constructing the actual data structures on demand: for example, we
> could add an implementation that doesn't actually build the data
> structures storing the symbols until the first time that an iterator
> is called.
> 
> I'm certainly willing to believe that the interface might change in
> the future; but separating the interface from the implementation is a
> good first step no matter what.
> 
> I kind of get the impression that I'm missing your point somehow and
> that we're talking past each other.  I'll post a concrete patch soon
> (Wednesday, maybe?  It's done on my laptop, but I don't have my laptop
> with me), and hopefully that will clarify matters.

Sounds like it.  I'm think I'm looking a step beyond your changes.

Is the block's symbol search algorithm determined by the language?  I 
believe it is, and hence it should be language specific code that 
constructs the blocks dictionary?  Of course it could also be 
implemented on-demand.

I think that would allow much C++ junk to be kicked out of the current 
symbol table readers.  Instead they just read in simple lists of symbols 
in blocks.

Andrew

Re: [rfc] struct dictionary

[David Carlton]

On Tue, 29 Apr 2003 16:06:02 -0400, Andrew Cagney <ac131313@redhat.com> said:

>> I kind of get the impression that I'm missing your point somehow
>> and that we're talking past each other.  I'll post a concrete patch
>> soon (Wednesday, maybe?  It's done on my laptop, but I don't have
>> my laptop with me), and hopefully that will clarify matters.

> Sounds like it.  I'm think I'm looking a step beyond your changes.

Good, because I think/hope so too.

> Is the block's symbol search algorithm determined by the language?

Sort of yes, sort of no.  lookup_block_symbol itself doesn't depend on
the language: it has one subtlety that depends, basically, on whether
or not the block is associated to a function, but that doesn't have
anything to do with the language.

But that's just lookup_block_symbol.  lookup_symbol itself implements
C/C++ name lookup, so if languages are too different from C or C++,
they might have to implement their own custom lookup rules.  And,
unfortunately, my current namespace patch that's awaiting review
increases the amount of C++-specific cruft in there.  It does it in
such a way that the C execution path shouldn't get slowed down, but
I'm still not happy with its presence at all: currently, GDB is too
C-centric, but changing that to being C++-centric isn't exactly an
improvement.  (For what it's worth, until my first namespace patch,
struct block didn't have a language_specific member at all.)

There shouldn't be anything in any of these functions that depends on
the language of the symbols themselves.  There's some code in various
functions to treat Java symbols differently when searching, but that
code really shouldn't be there.

I have some ideas about representing things like using directives,
anonymous namespaces, namespace scope, and for that matter the simple
case of looking up a C global variable in terms of dictionaries.  I
want to get things working first in a way that is, I think, not too
hard to understand, but I hope there will be time to reflect on the
situation later and change the implementations to move more of the
C++-specific code to a more appropriate location.

One issue that we'll have to grapple with is that the
language-specific rules aren't really localized to a single block.
For example, name lookup looks something like this:

1) Look in local variables.

2) Look to see if we're referring to a member of the current class.

3) Look in global and static variables.

Now, step #2 isn't relevant to C, and for that matter I would imagine
that different object-oriented language might have some subtle
differences in the exact semantics of step #2.  So it's a good
candidate for a language-specific hook: but where should the hook go?
We don't want to do this all the time, after all: only if we're
executing a member function.  And currently that information doesn't
really fit into our blocks at all.

I can imagine possible solutions.  One is to move BLOCK_SUPERBLOCK
inside of dictionaries, and then allow dictionaries to implement their
own strategies for what do do next (basically, to let them implement
lookup_symbol instead of just lookup_block_symbol).  Another
possibility would be to, when creating the block associated to a
method, have its superblock not be the current file's static block but
instead be a dummy block that exists only to provide a dictionary to
lookup a member of the current class.  (Of course, this also raises
the problem that members aren't represented by symbols: so what do we
do about that?)  I'm sure that there are other possibilities as well;
I'm not sure which of them is best.  And I also don't know exactly
what effects this will have on the symbol readers.

David Carlton
carlton@math.stanford.edu

Re: [rfc] struct dictionary

[Andrew Cagney]

Jim,

Is it ok to remove BLOCK_SHOULD_SORT how?

Andrew

Re: [rfc] struct dictionary

[Andrew Cagney]

> Jim,

Jim (Elena?)

> Is it ok to remove BLOCK_SHOULD_SORT how?
> 
> Andrew
> 
> 

Re: [rfc] struct dictionary

[Elena Zannoni]

Andrew Cagney writes:
 > > Jim,
 > 
 > Jim (Elena?)
 > 
 > > Is it ok to remove BLOCK_SHOULD_SORT how?
 > > 
 > > Andrew
 > > 
 > > 
 > 

a thousand and one, and two, and three...sold to the old lady in the
pink suit...

Sure.

David, do you want to resuscitate your old patch? Consider it preapproved.

elena

Re: [rfc] struct dictionary

[David Carlton]

On Mon, 2 Jun 2003 22:25:54 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> Andrew Cagney writes:

>>> Is it ok to remove BLOCK_SHOULD_SORT how?

> a thousand and one, and two, and three...sold to the old lady in the
> pink suit...

> Sure.

> David, do you want to resuscitate your old patch? Consider it preapproved.

Honesly, I don't see too much urgency in doing it if the dictionary
patch doesn't get approved.  (The dictionary patch would make
BLOCK_SHOULD_SORT obsolete.)  If it's bothering anybody else, I'll get
rid of BLOCK_SHOULD_SORT now, but otherwise I'll just wait for a
verdict on the dictionary patch.

David Carlton
carlton@math.stanford.edu