On 05/17/18 15:39, Richard Biener wrote: > On Thu, May 17, 2018 at 3:21 PM Bernd Edlinger <bernd.edlin...@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. >>>>