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

Richard Biener
Wed Aug 5 16:55:55 GMT 2020

On August 5, 2020 5:41:01 PM GMT+02:00, Aldy Hernandez via Gcc-patches <> wrote:
>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
>>> in our internal vec<> implementation.  Although we usually steer
>>> from using std::vec because of interactions with our GC system,
>>> ipcp_param_lattices is only live within the pass and allocated with
>> Ummm... I did not object but I will save the URL of this message in
>> 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,
>> 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
>with our GC?  Is GCC's vec<> that much faster/efficient than
>  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?

Note we generally want to avoid memory allocations per element so can't you use a value_range<1> or so to make it POD? 



More information about the Gcc-patches mailing list