[Bug middle-end/90904] vec assignment and copying undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #7 from Martin Sebor --- I'm no longer working on this.
[Bug middle-end/90904] vec assignment and copying undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904 Martin Sebor changed: What|Removed |Added Keywords||patch Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568765.html
[Bug middle-end/90904] vec assignment and copying undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904 --- Comment #5 from Martin Sebor --- Looks like move ctor/assignment have been added to auto_vec in g:4b9d61f79c0c0185a33048ae6cc72269cf7efa31 but not copy ctor/assignment.
[Bug middle-end/90904] vec assignment and copying undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904 --- Comment #4 from rguenther at suse dot de --- On Tue, 18 Jun 2019, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904 > > --- Comment #3 from Martin Sebor --- > (In reply to Richard Biener from comment #1) > > I ran into a similar issue while trying > > > > hash_map > > > > > where copying fails to adjust the pointer to the in-place storage giving > > even more obscure errors. > > That's exactly what just happened to me. It has led to bizarre > miscompilations. How did you get around this? Use a plain vec and manage the > copying yourself? Yes, use a plain hash_map > and pay the price of one memory allocation per hash entry (the vec length is <= 1 in 95% of the cases for rpo_avail_t ...)
[Bug middle-end/90904] vec assignment and copying undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904 --- Comment #3 from Martin Sebor --- (In reply to Richard Biener from comment #1) > I ran into a similar issue while trying > > hash_map > > > where copying fails to adjust the pointer to the in-place storage giving > even more obscure errors. That's exactly what just happened to me. It has led to bizarre miscompilations. How did you get around this? Use a plain vec and manage the copying yourself?
[Bug middle-end/90904] vec assignment and copying undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904 --- Comment #2 from Jonathan Wakely --- Declare them private, but don't define them. In 99.9% of cases you'll get an error at compile time for trying to use a private member. If the use happens from inside the class itself, the private member will be accessible and you'll get an error at link time. That still seems vastly better than just compiling and then crashing.
[Bug middle-end/90904] vec assignment and copying undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-18 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I ran into a similar issue while trying hash_map > where copying fails to adjust the pointer to the in-place storage giving even more obscure errors. And the conclusion was that we want move semantics here but that's not possible with the current constraints on C++ we can use. Disabling the copy ctor is probably most sensible at the moment but the only C++04 way is to have it result in a link error (or maybe some other obscure failue?).
