On Tue, Jan 24, 2017 at 1:31 PM, Nathan Sidwell <nat...@acm.org> wrote:
> 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?
I'm not seeing the patch.
Jason
