On 8/24/20 5:53 PM, Jeff Law wrote:
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
project.
jeff
I think there were adjustments made to gcc's vec, and the usage of
std::vector is no longer present..
I also think it was not a long term perfect solution, but adequate for
our needs at the moment.
Personally, I have no issue with std::vector when approriate.. too bad
we can make it adequate for all our usage :-P That is a much bigger
issue I am afraid.
Andrew
