[PING] [PATCH] Avoid excessive function type casts with splay-trees

Bernd Edlinger bernd.edlinger@hotmail.de
Thu May 17 14:58:00 GMT 2018


On 05/17/18 15:39, Richard Biener wrote:
> On Thu, May 17, 2018 at 3:21 PM Bernd Edlinger <bernd.edlinger@hotmail.de>
> wrote:
> 
>> Ping...
> 
> So this makes all traditional users go through the indirect
> splay_tree_compare_wrapper
> and friends (which is also exported for no good reason?).  And all users
> are traditional
> at the moment.
> 

all except gcc/typed-splay-tree.h which only works if VALUE_TYPE is
compatible with uint_ptr_t but cannot check this requirement.
This one worried me the most.

But not having to rewrite omp-low.c for instance where splay_tree_lookup
and access to n->value are made all the time, made me think it
will not work to rip out the old interface completely.


Bernd.

> So I wonder if it's better to have a complete alternate interface?  I do
> not see many
> users besides gcc, there's a use in bfd elf32-xtensa.c and some uses in
> gdb.  Of course
> disregarding any users outside of SRC.
> 
> Richard.
> 
> 
>> On 05/03/18 22:13, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this is basically the same patch I posted a few months ago,
>>> with a few formatting nits by Jakub fixed.
>>>
>>> Bootstrapped and reg-tested again with current trunk.
>>>
>>> Is it OK for trunk?
>>>
>>>
>>> Bernd.
>>>
>>> On 12/15/17 11:44, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> when working on the -Wcast-function-type patch I noticed some rather
>>>> ugly and non-portable function type casts that are necessary to
>>>> accomplish
>>>> some actually very simple tasks.
>>>>
>>>> Often functions taking pointer arguments are called with a different
>>>> signature
>>>> taking uintptr_t arguments, which is IMHO not really safe to do...
>>>>
>>>> The attached patch adds a context argument to the callback functions
> but
>>>> keeps the existing interface as far as possible.
>>>>
>>>>
>>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>>>> Is it OK for trunk?
>>>>
>>>>
>>>> Thanks
>>>> Bernd.
>>>>


More information about the Gcc-patches mailing list