-Wclass-memaccess warning should be in -Wextra, not -Wall

[Marc Glisse]

On Fri, 6 Jul 2018, Martin Sebor wrote:

> On 07/05/2018 05:14 PM, Soul Studios wrote:
>> Simply because a struct has a constructor does not mean it isn't a
>> viable target/source for use with memcpy/memmove/memset.
>
> As the documentation that Segher quoted explains, it does
> mean exactly that.
>
> Some classes have user-defined copy and default ctors with
> the same effect as memcpy/memset.  In modern C++ those ctors
> should be defaulted (= default) and GCC should emit optimal
> code for them.

What if I want to memcpy a std::pair<int,int>?

Some classes may have several states, some that are memcpy-safe, and some 
that are not. A user may know that at some point in their program, all the 
objects in a given array are safe, and want to memcpy the whole array 
somewhere.

memcpy can also be used to work around the lack of a destructive move in 
C++. For instance, vector<vector<T>>::resize could safely use memcpy (and 
skip destroy before deallocate). In this particular case, we could imagine 
at some point in the future that the compiler would notice it is 
equivalent to memcpy+bzero, and then that the bzero is dead, but there are 
more complicated use cases for destructive move.

> In fact, in loops they can result in more
> efficient code than the equivalent memset/memcpy calls.  In
> any case, "native" operations lend themselves more readily
> to code analysis than raw memory accesses and as a result
> allow all compilers (not just GCC) do a better a job of
> detecting bugs or performing interesting transformations
> that they may not be able to do otherwise.
>
>> Having benchmarked the alternatives memcpy/memmove/memset definitely
>> makes a difference in various scenarios.
>
> Please open bugs with small test cases showing
> the inefficiencies so the optimizers can be improved.

Some already exist (PR 86024 seems related, there are probably some closer 
matches), but indeed more would be helpful.

-- 
Marc Glisse