On Wed, May 16, 2018 at 2:58 AM Jason Merrill <ja...@redhat.com> wrote:
> In C++11 and up, the implicitly-declared copy constructor and > assignment operator are deprecated if one of them, or the destructor, > is user-provided. Implementing that in G++ turned up a few dodgy uses > in the compiler. > In general it's unsafe to copy an ipa_edge_args, because if one of the > pointers is non-null you get two copies of a vec pointer, and when one > of the objects is destroyed it frees the vec and leaves the other > object pointing to freed memory. This specific example is safe > because it only copies from an object with null pointers, but it would > be better to avoid the copy. OK for trunk? > It's unsafe to copy a releasing_vec for the same reason. There are a > few places where the copy constructor is nominally used to initialize > a releasing_vec variable from a temporary returned from a function; in > these cases no actual copy is done, and the function directly > initializes the variable, so it's safe. I made this clearer by > declaring the copy constructor but not defining it, so uses that get > elided are accepted, but uses that actually want to copy will fail to > link. > In cp_expr we defined the copy constructor to do the same thing that > the implicit definition would do, causing the copy assignment operator > to be deprecated. We don't need the copy constructor, so let's remove > it. > Tested x86_64-pc-linux-gnu. Are the ipa-prop bits OK for trunk? Yes. Richard.
