Hi,
On Mon, 12 Nov 2018, Martin Liška wrote:
> > There's no fundamental reason why we can't poison identifiers in other
> > headers. Indeed we do in vec.h. So move the whole thing including
> > poisoning to hash-table.h?
>
> That's not feasible as gcc/gcc/genhooks.c files use the function an
On 11/9/18 2:28 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 8 Nov 2018, Martin Liška wrote:
>
>>> That seems better. But still, why declare this in system.h? It seems
>>> hash-table.h seems more appropriate.
>>
>> I need to declare it before I'll poison it. As system.h is included very
>> early
Hi,
On Thu, 8 Nov 2018, Martin Liška wrote:
> > That seems better. But still, why declare this in system.h? It seems
> > hash-table.h seems more appropriate.
>
> I need to declare it before I'll poison it. As system.h is included very
> early, one can guarantee that there will be no usage be
On 11/8/18 2:15 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 7 Nov 2018, Martin Liška wrote:
>
>>> Whereever the new function belongs it certainly isn't system.h. Also
>>> the definition in a header seems excessive. Sure, it enables inlining
>>> of it, but that seems premature optimization. It
Hi,
On Wed, 7 Nov 2018, Martin Liška wrote:
> > Whereever the new function belongs it certainly isn't system.h. Also
> > the definition in a header seems excessive. Sure, it enables inlining
> > of it, but that seems premature optimization. It contains a loop, and
> > inlining anything with
On 11/5/18 7:37 PM, Michael Matz wrote:
> Hi,
>
> On Fri, 2 Nov 2018, Martin Liška wrote:
>
>> V2 of the patch.
>>
>> Thoughts?
>
Hi.
> Whereever the new function belongs it certainly isn't system.h. Also the
> definition in a header seems excessive. Sure, it enables inlining of it,
> but
Hi,
On Fri, 2 Nov 2018, Martin Liška wrote:
> V2 of the patch.
>
> Thoughts?
Whereever the new function belongs it certainly isn't system.h. Also the
definition in a header seems excessive. Sure, it enables inlining of it,
but that seems premature optimization. It contains a loop, and inli
V2 of the patch.
Thoughts?
Martin
>From 484d6d29292f210946f9d5091273eb9e1796c874 Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 2 Nov 2018 10:15:10 +0100
Subject: [PATCH] Come up with htab_hash_string_vptr and use string-specific if
possible.
gcc/ChangeLog:
2018-11-02 Martin Li
On 11/2/18 9:02 AM, Richard Biener wrote:
> On Wed, Oct 31, 2018 at 5:40 PM Martin Liška wrote:
>>
>> Hi.
>>
>> As seen in r265663 having htab_hash_string accepting const char * would
>> report a compilation error. The void * argument is needed for old C-style
>> htab used in libiberty. I'm sugges
On Wed, Oct 31, 2018 at 5:40 PM Martin Liška wrote:
>
> Hi.
>
> As seen in r265663 having htab_hash_string accepting const char * would
> report a compilation error. The void * argument is needed for old C-style
> htab used in libiberty. I'm suggesting to come up with htab_hash_string_vptr
> and
Hi.
As seen in r265663 having htab_hash_string accepting const char * would
report a compilation error. The void * argument is needed for old C-style
htab used in libiberty. I'm suggesting to come up with htab_hash_string_vptr and
change signature of the old one (htab_hash_string). And putting the
11 matches
Mail list logo
