On August 5, 2020 5:41:01 PM GMT+02:00, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> 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. > >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?
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? Richard. >Aldy
