On 21/01/20 23:04 -0300, Alexandre Oliva wrote:
On Jan 21, 2020, Jonathan Wakely <jwak...@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.
