33,38
--- 33,39
#endif
#include
+ #include
#include "libiberty.h"
#include "splay-tree.h"
*******
*** 557,559
--- 558,570
else
return 0;
}
+
+ /* Splay-tree comparison function, treating the keys as strings. */
+
+ int
+ splay_t
Michael Matz writes:
> On Tue, 5 Jul 2011, Richard Sandiford wrote:
>> FWIW, the reason I asked was because I'm using a splay tree in a patch
>> that I hope to send soon. The libiberty structures are a bit heavyweight,
>> with the hooks stored alongside the root p
Hi,
On Tue, 5 Jul 2011, Richard Sandiford wrote:
> FWIW, the reason I asked was because I'm using a splay tree in a patch
> that I hope to send soon. The libiberty structures are a bit heavyweight,
> with the hooks stored alongside the root pointer, and with each node
>
Michael Matz writes:
>> > There were other people pointing out issues with the splay tree (but
>> > all w/o copyright assignment and much larger patches).
>> >
>> > I know I did the last re-write of this piece of code but it's been a
>> > lon
Hi,
On Mon, 4 Jul 2011, Michael Matz wrote:
> > There were other people pointing out issues with the splay tree (but
> > all w/o copyright assignment and much larger patches).
> >
> > I know I did the last re-write of this piece of code but it's been a
> >
Hi,
On Mon, 4 Jul 2011, Richard Guenther wrote:
> There were other people pointing out issues with the splay tree (but all
> w/o copyright assignment and much larger patches).
>
> I know I did the last re-write of this piece of code but it's been a
> long time ... i
Z C ---> A Y > Y D
> / \ / \ / \
> A B B C B C
>
> (The other two cases seem fine.)
There were other people pointing out issues with the splay tree
(but all w/o copyright ass
OK, I know I'm embarrassing myself here, but is libiberty's splay-tree.c
doing the right thing for the zig-zig and zag-zag cases? The code reads:
/* Now we have the four cases of double-rotation. */
if (cmp1 < 0 && cmp2 < 0)
{
rotate_left (&n->left, c, c->left);
rot
Got the documents signed and they are now on their
way.
--- Richard Guenther <[EMAIL PROTECTED]>
wrote:
> On 11/3/06, Ian Blanes <[EMAIL PROTECTED]> wrote:
> >
> > The original author of this patch said he sent his
> copyright assignment. I
> > only did minor modification to his work so I don't
> Brian Makin writes:
Brian> I had sent in the paperwork in october 2005.
Brian> [EMAIL PROTECTED]
Brian> Brian N. Makin
Brian> I can certainly send another if necessary.
Did you send in a request for an assignment or did you fill out an
assignment yourself? Did you receive an ackno
I had sent in the paperwork in october 2005.
[EMAIL PROTECTED]
Brian N. Makin
I can certainly send another if necessary.
--- Richard Guenther <[EMAIL PROTECTED]>
wrote:
> On 11/3/06, Ian Blanes <[EMAIL PROTECTED]> wrote:
> >
> > The original author of this patch said he sent his
> copyright ass
On 11/3/06, Ian Blanes <[EMAIL PROTECTED]> wrote:
The original author of this patch said he sent his copyright assignment. I
only did minor modification to his work so I don't I think I should send
it too.
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00833.html
There doesn't seem to be an assi
The original author of this patch said he sent his copyright assignment. I
only did minor modification to his work so I don't I think I should send
it too.
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00833.html
I already did a bootstrap and check to be sure it worked right when I
first sent
> Could this patch be applied now?
> http://gcc.gnu.org/ml/gcc/2006-07/msg00210.html
Assuming it's been bootstrapped with no regressions, and the legal
paperwork is in place, yes.
been recently looking at the splay tree implementation. I've noticed
that this revision http://gcc.gnu.org/viewcvs?view=rev&revision=106584
does a strange splaying. It does a bottom up splaying but starting at the
root (not the same that top down). It works but performs worst. One
exam
I looked at the splay tree code in revision 106584.
It doesn't appear to actually be doing a top down
splay.
It is performing a top down partition of the tree but
without the splay step. This should cause some cases
to perform quite badly.
I'm pretty sure my original patch does th
.html
I realized that 3 orders of magnitude of diference wasn't a very realistic
benchmark. So I reviewed it. I found that I forgot some profiling code
that was biasing the result of the revision 106584, and that the pice
of splay tree usage used to perform the benchmark wasn't so rep
Hi Ian,
On Sun, 9 Jul 2006, Ian Blanes wrote:
> I've been recently looking at the splay tree implementation. I've noticed
> that this revision http://gcc.gnu.org/viewcvs?view=rev&revision=106584
> does a strange splaying. It does a bottom up splaying but starting at the
&g
18 matches
Mail list logo
