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

[Soul Studios]

> 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.  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.
> 
> Martin
> 


My point to all of this (and I'm annoyed that I'm having to repeat it 
again, as it my first post wasn't clear enough - which it was) was that 
any programmer using memcpy/memmove/memset is going to know what they're 
getting into.
Therefore it makes no sense to penalize them by getting them to write 
ugly, needless code - regardless of the surrounding politics/codewars.
Extra seems an amiable place to put this, All doesn't.

As for test cases, well, this is something I've benchmarked over a range 
of scenarios in various projects over the past 3 years (mainly 
plf::colony and plf::list).
If I have time I'll submit a sample.