Re: [committed] Fix -Werror=class-memaccess failures in jit testsuite (PR jit/81144)

[Martin Sebor <msebor at gmail dot com>]

On 06/20/2017 03:25 PM, David Malcolm wrote:
> This patch fixes a couple of failures of the form:
>
>   error: 'void* memset(void*, int, size_t)' clearing an object of non-trivial
>     type 'struct quadratic_test'; use assignment or value-initialization
>     instead [-Werror=class-memaccess]
>   note: 'struct quadratic_test' declared here
>   cc1plus: all warnings being treated as errors
>
> seen within the jit testsuite, by using zero-initialization instead
> of memset.
>
> (presumably introduced by r249234 aka a324786b4ded9047d05463b4bce9d238b6c6b3ef)
>
> Successfully tested on x86_64-pc-linux-gnu; takes jit.sum from:
>   # of expected passes            9211
>   # of unexpected failures        2
> to:
>   # of expected passes            9349
>
> Martin: it's unclear to me what the benefit of the warning is for these
> cases.  AIUI, it's complaining because the code is calling
> the default ctor for struct quadratic_test, and then that object is
> being clobbered by the memset.
> But if I'm reading things right, the default ctor for this struct
> zero-initializes all fields.  Can't the compiler simply optimize away
> the redundant memset, and not issue a warning?

-Wclass-memaccess is issued because struct quadratic_test contains
members of classes that define a default ctor to initialize their
private members.  The premise behind the warning is that objects
of types with user-defined default and copy ctors should be
initialized by making use of their ctors, and those with private
data members manipulated via member functions rather than by
directly modifying their raw representation.  Using memset to
bypass the default ctor doesn't begin the lifetime of an object,
can violate invariants set up by it, and using it to overwrite
private members breaks encapsulation.  Examples of especially
insidious errors include overwriting const data, references, or
pointer to data members for which zero-initialization isn't
the same as clearing their bytes.

The warning runs early on in the C++ front end and has no knowledge
of either the effects of the type's ctors, dtor, and copy assignment
operator, or whether the raw memory function is called in lieu of
initializing an object (e.g., in storage obtained from malloc or
operator new), or as a shortcut to zero out its members, or when
zeroing them out happens to be safe and doesn't actually do any
of those bad things I mentioned above.

That said, I'm sorry (and a little surprised) that I missed these
errors in my tests.  I thought I had all the languages covered by
using

  --enable-languages=all,ada,c,c++,fortran,go,lto,objc,obj-c++

but I guess jit still isn't implied by all, even after Nathan's
recent change to it.  Let me add jit to my script (IIRC, I once
had it there but it was causing some trouble and I took it out.)

Martin