Re: std:vec for classes with constructor? (Was: Re: [patch] multi-range implementation for value_range (irange))

[Aldy Hernandez <aldyh@redhat.com>]

On 8/5/20 5:09 PM, Martin Jambor wrote:

> On Fri, Jul 31 2020, Aldy Hernandez via Gcc-patches wrote:
>>
> 
> [...]
> 
>>
>> * ipa-cp changes from vec<value_range> to std::vec<value_range>.
>>
>> We are using std::vec to ensure constructors are run, which they aren't
>> in our internal vec<> implementation.  Although we usually steer away
>> from using std::vec because of interactions with our GC system,
>> ipcp_param_lattices is only live within the pass and allocated with calloc.
>>
> 
> Ummm... I did not object but I will save the URL of this message in the
> archive so that I can waive it in front of anyone complaining why I
> don't use our internal vec's in IPA data structures.
> 
> But it actually raises a broader question: was this supposed to be an
> exception, allowed only not to complicate the irange patch further, or
> will this be generally accepted thing to do when someone wants to have a
> vector of constructed items?

I don't want to start a precedent without further discussion, so let's 
assume this was an exception.

Is there another objection to std::vec<> other than it doesn't play well 
with our GC?  Is GCC's vec<> that much faster/efficient than std::vec<>? 
  Does it matter?

I will note that an alternative would have been to rewrite our 
internal's vec<> implementation so that constructors are run.  We 
explored that, but it seemed like more work than it was worth.

Andrew, do you remember the details on the C++ness issues with GCC's 
vec<> implementation?

Aldy