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

Jeff Law
Mon Aug 24 21:53:27 GMT 2020

On Wed, 2020-08-05 at 17:41 +0200, Aldy Hernandez 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 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.
I'd characterize it as an exception too.  When I looked at the patch for Aldy, I
called out this code as well and asked him to justify it and convince me it was
safe, which he did.  I'd to the same for anything else adding use of a standard
C++ container to hold a GC-able object.

I'd certainly like to get to a place where we could be using more standard C++
library components.  But it'll take time to get there and consensus within the


More information about the Gcc-patches mailing list