On Mon, Jan 4, 2021 at 4:43 PM Richard Sandiford via Gcc-patches
wrote:
>
> Andreas Schwab writes:
> > On Jan 04 2021, Richard Sandiford wrote:
> >
> >> Andreas Schwab writes:
> >>> That doesn't build with gcc 4.8:
> >>
> >> Which subversion are you using?
> >
> > This is 4.8.1.
>
> Hmm, OK. I
Andreas Schwab writes:
> On Jan 04 2021, Richard Sandiford wrote:
>
>> Andreas Schwab writes:
>>> That doesn't build with gcc 4.8:
>>
>> Which subversion are you using?
>
> This is 4.8.1.
Hmm, OK. I guess that raises the question whether “supporting GCC 4.8”
means supporting every patchlevel, o
On 12/16/20 5:29 PM, Richard Sandiford wrote:
> Jeff Law writes:
>> On 11/13/20 1:15 AM, Richard Sandiford via Gcc-patches wrote:
>>> We already have two splay tree implementations: the old C one in
>>> libiberty and a templated reimplementation of it in typed-splay-tree.h.
>>> However, they ha
On Jan 04 2021, Richard Sandiford wrote:
> Andreas Schwab writes:
>> That doesn't build with gcc 4.8:
>
> Which subversion are you using?
This is 4.8.1.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for some
Andreas Schwab writes:
> That doesn't build with gcc 4.8:
Which subversion are you using? It works for me with stock gcc 4.8.5,
which is what I'd used to test the series for C++ compatiblity.
Richard
>
> In file included from ../../gcc/splay-tree-utils.h:491:0,
> from ../../gc
That doesn't build with gcc 4.8:
In file included from ../../gcc/splay-tree-utils.h:491:0,
from ../../gcc/rtl-ssa.h:45,
from ../../gcc/fwprop.c:29:
../../gcc/splay-tree-utils.tcc:24:1: error: prototype for 'typename
base_splay_tree::node_type
base_splay_tree::ge
Jeff Law writes:
> On 11/13/20 1:15 AM, Richard Sandiford via Gcc-patches wrote:
>> We already have two splay tree implementations: the old C one in
>> libiberty and a templated reimplementation of it in typed-splay-tree.h.
>> However, they have some drawbacks:
>>
>> - They hard-code the assumptio
On 11/13/20 1:15 AM, Richard Sandiford via Gcc-patches wrote:
> We already have two splay tree implementations: the old C one in
> libiberty and a templated reimplementation of it in typed-splay-tree.h.
> However, they have some drawbacks:
>
> - They hard-code the assumption that nodes should ha
We already have two splay tree implementations: the old C one in
libiberty and a templated reimplementation of it in typed-splay-tree.h.
However, they have some drawbacks:
- They hard-code the assumption that nodes should have both a key and
a value, which isn't always true.
- They use the two-
