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
