> On Dec 22, 2020, at 8:52 PM, Hao Sun > <github.com+16932759+shqk...@openjdk.java.net> wrote: > > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-known Rule of Three [2]. > > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' > warns about the C++11 deprecation of implicitly declared copy > constructor and assignment operator if one of them is user-provided. > Defining an explicit copy constructor would suppress this warning. > > The main reason why debug build with gcc-9 or higher succeeds lies in > the inconsistent warning behaviors between gcc and clang. See the > reduced code example [5]. We suspect it might be return value > optimization/copy elision [6] that drives gcc not to declare implicit > copy constructor for this case.
C++17 "guaranteed copy elision" is implemented in gcc7. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html Using -fno-elide-constructors makes it obvious that the deprecated implicit copy constructors are indeed being elided, so no deprecation warning. Why doesn't this patch similarly define DUIterator copy constructor? It seems to have the same issue, and I'm surprised clang-10 didn't complain about it too. Certainly gcc with -fno-elide-constructors complains about the defaulted implicit constructor. But I discovered something alarming while experimenting. Building with gcc10.2 with -fno-elide-constructors doesn't seem to be possible. I get different kinds of failures depending on how DUIterator is defined: - implict: deprecation warning (as expected) - =delete: error, deleted function used - =default: assert in os::free - _idx and reset from that: assert in reset Without -fno-elide-constructors, all of the variants seem to work except =delete, which still fails because the deleted function is used. (I didn't test the "working" cases extensively though.) So there's something problematic, though I don't understand the code well enough to understand what. Interestingly, some of the complexity and weirdness around copy/assign for these classes may be an attempt at providing something like move semantics in a C++98 code base. I've noticed a number of places in HotSpot that are doing that. Defining DUIterator_Fast and DUIterator_Last as movable but not copyable (explicitly delete the copy constructor and copy assign operator, and define the move constructor and move assign operator with the reset) works, even with -fno-elide-constructors.