adlc-generated operator= for Pipeline_Use_Cycle_Mask

[Kim Barrett]

> On Nov 11, 2019, at 10:40 AM, Florian Weimer <fweimer at redhat.com> wrote:
> 
> adlc generates an assignment operator for the  Pipeline_Use_Cycle_Mask
> class, like this:
> 
>  Pipeline_Use_Cycle_Mask& operator=(const Pipeline_Use_Cycle_Mask &in) {
>    _mask = in._mask;
>    return *this;
>  }
> 
> GCC 10 takes this as an indicator that objects of this class should not
> be modified with memcpy or memset and issues -Wclass-memaccess warnings:
> 
> …/src/hotspot/share/opto/output.cpp: In constructor 'Scheduling::Scheduling(Arena*, Compile&)':
> …/src/hotspot/share/opto/output.cpp:1745:108: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class Pipeline_Use_Element' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess]
> 1745 |   memcpy(_bundle_use_elements, Pipeline_Use::elaborated_elements, sizeof(Pipeline_Use::elaborated_elements));
>      |                                                                                                            ^
> In file included from …/src/hotspot/share/opto/ad.hpp:31,
>                 from …/src/hotspot/share/opto/output.cpp:37:
> ad_x86.hpp:6196:7: note: 'class Pipeline_Use_Element' declared here
> …/src/hotspot/share/opto/output.cpp: In member function 'void Scheduling::step_and_clear()':
> …/src/hotspot/share/opto/output.cpp:1797:51: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class Pipeline_Use_Element' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess]
> 1797 |          sizeof(Pipeline_Use::elaborated_elements));
>      |                                                   ^
> 
> Looking at the code generator, it seems that the default assignment
> operator will do the right thing in all cases.  Can we remove generation
> of this C++ code fragment?
> 
> Thanks,
> Florian

I agree with that analysis and the suggested solution approach.  I’ve filed a bug for this issue:
https://bugs.openjdk.java.net/browse/JDK-8233941