[C++ PATCH] Fix lambda capture duplicate handling (PR c++/89767)

[Nathan Sidwell]

On 3/20/19 10:48 AM, Jakub Jelinek wrote:
> On Wed, Mar 20, 2019 at 10:34:51AM -0400, Nathan Sidwell wrote:
>> On 3/19/19 2:14 PM, Jakub Jelinek wrote:
>>> add_capture when parsing a lambda introducer uses the IDENTIFIER_MARKED
>>> bit to detect duplicate captures.
>>> I guess in strict C++11 that could have worked, if the introducer could
>>> contain just identifiers, but in C++14 it has 2 problems:
>>
>>> The following patch stops using IDENTIFIER_MARKED for this and uses a
>>> hash_set instead.  But, as I believe lambdas with 0 (or very few) explicit
>>> captures are extremely common, I've tried not to slow down those with
>>> allocation of a hash_set and deallocating it again, so it uses
>>> a linear search if there are up to 8 captures and starts using a hash_set
>>> only when getting above that count.
>>>
>>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>>
>>> Or do you think allocation of an hash_set and deallocation would be in a
>>> noise?
>>
>> I think it'd be in the noise.  The high bit is between zero and more than
>> zero captures. The next most common after zero would be 1. Besides,
>> identifiers are trivial to hash.
> 
> What I meant is that even just hash_set<tree> var; implies a xcalloc (13,
> sizeof (void*)) or so and destroying it a free of that.
> So, if 90% of all lambdas in the headers have zero captures and 5% have 1,
> then simplifying the patch by adding that hash_set<tree> var; into the
> lambda introducer parsing routine and just always using the hash set would
> add those to the parsing of all those 95%+ lambda parsings that don't really
> need that.
> 
> Here is attached completely untested variant that does that unconditional
> xcalloc/free for every lambda introducer parsing.

I was unclear.  I was for the lazy creation of the hash.  I just think 
it can be lazily created at either the first or second explicit capture.

nathan

-- 
Nathan Sidwell