tolerate padding in mbstate_t

[Jonathan Wakely]

On 21/01/20 23:04 -0300, Alexandre Oliva wrote:
>On Jan 21, 2020, Jonathan Wakely <jwakely@redhat.com> wrote:
>
>> On 21/01/20 21:36 -0300, Alexandre Oliva wrote:
>>>
>>> Padding in mbstate_t objects may get the memcmp to fail.
>>> Attempt to avoid the failure with zero initialization.
>>>
>>>
>>> Regstrapped on x86_64-linux-gnu, and also tested on a platform that used
>>> to fail because of padding in std::mbstate_t.  Ok to install?
>
>> Under what conditions does this fail? Only for -std=gnu++98 and not
>> later standards, I assume?
>
>> Because since C++11 state_type() does perform zero-initialization of
>> the whole object (including padding) even if it has a default
>> constructor.
>
>Err, IIUC it does so only for defaulted ctors; a user-supplied default
>ctor (as in the target system) may leave padding bits uninitialized.

Yes, I misremembered.

>Indeed, compiling the following snippet without optimization, with or
>without -DCTOR, on x86_64, uses movw to initialize bar and the rest of
>the word remains uninitialized with -DCTOR, even with -std=c++17, as we
>do without -DCTOR with -std=c++98, whereas without -DCTOR and
>-std=c++1[17] we use movq.
>
>struct t {
>  long foo;
>  short bar;
>#if CTOR
>  t() : foo(0), bar(0) {}
>#endif
>};
>t f() {
>  t v = t();
>  return v;
>}

Right. I was confusing it with this case:

struct t2 : t { };

t2 g() {
   t2 v = t2();
   return v;
}

This one *does* zero-initialize the padding in struct t, even though
it has a user-provided default constructor.

>When optimiizing, we end up using movq in all cases, but that's probably
>because of SRA.
>
>
>> I don't think so, that wouldn't work. I think pos02 could just be
>> removed from the test.
>
>Will do.

Thanks, OK to commit.