On 01/23/2017 04:06 PM, Jason Merrill wrote:
In this particular case we've also made the base object the containing
class, not the unnamed struct member. That means we're looking in the wrong
CONSTRUCTOR and see CONSTRUCTOR_NO_IMPLICIT_ZERO is true. Whereas for the
subobj's CONSTRUCTOR it is false.
Why is it false?
I thought it was because we're looking at a different level of ctor,
investigation shows there may be a bug there too. because in one place
we do:
if (*valp == NULL_TREE)
{
*valp = build_constructor (type, NULL);
CONSTRUCTOR_NO_IMPLICIT_ZERO (*valp) = no_zero_init;
and another we do:
if (vec_safe_is_empty (*vec)
|| (*vec)->last().index != field)
{
ctor = build_constructor (TREE_TYPE (field), NULL);
CONSTRUCTOR_APPEND_ELT (*vec, field, ctor);
However, further looking at this problem, I discovered we're not
properly checking the initialization of anonymous members. Once we do
that, we reject the ctor as a constexpr, because it fails to initialize
the 'type' member (regardless of bitfieldness).
This patch augments cx_check_missing_mem_inits. I change the first parm
to be the CTYPE not the FUN from whence we pull the CTYPE. That way we
don't have to cons up an empty CONSTRUCTOR for the recursive case of
discovering no initializer at all for the anon member.
With this in place we don't try and evaluate the constexpr in the
original testcase.
ok?
nathan
--
Nathan Sidwell